[Bug 8365] Remove the Web Browsers Section 6

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





--- Comment #9 from Shelley Powers <shelleyp@burningbird.net>  2009-11-24 23:41:59 ---
(In reply to comment #7)
> Thinking some more about Section 6, I think there are several properties of
> some but not all UAs that affect whether particular sections are applicable:
> 
> - Navigation - is it possible to go to a new page, either in the top level
> context or a subframe, or to jump to a specific fragment identifier?
> - Frames - does the UA support frames, iframes, or nested HTML via <object>?
> - Link Traversal - is it possible to follow a link, either in the same place or
> in a new window/tab/whatever?
> - Scripting - does the UA support script execution and associated APIs?
> - Networking - does the UA support loading of subresources from remote
> locations, and not just bundled resources (like mail attatchments) or specific
> hardcoded local files?
> - Same-Origin Security - does the UA need to interact with the same-origin
> security model in any way?
> 
> Here's how I think the applicability goes:
> 
> 6.1 Browsing contexts
>     Navigation or Frames or Link Traversal or Same-Origin Security
> 6.2 The WindowProxy object
>     Scripting
> 6.3 The Window object
>     Scripting
> 6.4 Origin
>     Same-Origin Security or Scripting or Networking or Link Traversal or
> Navigation
> 6.5 Scripting
>     Scripting
> 6.6 Timers
>     Scripting
> 6.7 User prompts
>     Scripting
> 6.8 System state and capabilities
>     Scripting
> 6.9 Offline Web applications
>     Networking (it would be pointless to put an a document that can only load
> fixed resources)
> 6.10 Session history and navigation
>     Scripting or navigation
> 6.11 Browsing the Web
>    all
> 6.12 Links
>    all
> 
> 6 of the 12 sections are only relevant to scripting UAs. Note though, that
> there is text throughout the spec that is only relevant to scripting UAs,
> including all the IDL interfaces (and definitions of their methods) and every
> time the spec says to dispatch an event. If the goal is to split out any
> requirements that are only relevant to scripting UAs, then removing section 6
> is far from achieving that goal.
> 
> Here's how I would classify the capabilities of the different kinds of UAs I
> mentioned:
> 
> Web browser
>     Navigation, Frames, Link Traversal, Scripting, Networking, Same-Origin
> Security
> Widget runtime
>     Navigation, Frames, Link Traversal, Scripting, Networking, Same-Origin
> Security
> Mail client
>     Frames, Link Traversal, Scripting, Networking, Same-Origin Security
> Chat app
>     Link Traversal
> Help viewer
>     Navigation, Frames, Link Traversal, Scripting, Networking, Same-Origin
> Security
> Widget IDE
>     Navigation, Frames, Link Traversal, Scripting, Networking, Same-Origin
> Security
> Dictionary
>     Navigation, Link Traversal
> Consumer-level Web page creator
>     Navigation, Frames, Link Traversal, Scripting, Networking, Same-Origin
> Security
> 
> Third party developers have developed eBook readers using WebKit, but I'm not
> aware of the details of the capabilities of these apps, or of defined eBook
> formats. Shelley, can you help me out? I assume from what you say that eBook
> formats don't support scripting. Do any of the other properties I mentioned
> apply? Do they do link traversal for instance? Are they able to navigate to
> fragments? Can they load remote resources?
> 

I imagine the section does have useful information. I'm not advocating trashing
the work. What I am advocating is refocusing the HTML specification back to
HTML, rather than on applications. 

To answer your question about eBooks, you can see what's supported in XHTML for
the open ePub format in this excellent MobileRead site
http://wiki.mobileread.com/wiki/EPUB. 

Navigation is actually managed through instructions in a separate XML file.
Remote resources are accessed, but they have to be listed in the manifest file. 

Now, it doesn't make use of all HTML elements. At the same time, the ePub folks
aren't coming into the HTML WG and demanding that we support OPF in HTML5,
either. Why? Because that's application specific, and doesn't have a place in a
general purpose language such as HTML.

All applications that make use of HTML or XHTML have their own requirements and
needs. The appropriate procedure is to define specifications for the
application functionality, and leave the HTML markup for the HTML WG.


-- 
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 23:42:09 UTC