This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently the HTML5 specification contains a section, Section 6, devoted specifically to browsers. The section also notes that though it is focused on browsers, requirements in the section apply to all user agents, not just browsers, unless otherwise noted. Though browsers are a major user agent for HTML/XHTML, they are not the only user agents. In particular, ebook technology is dependent on XHTML, and forms a completely different class of user agents than browsers. In addition, there are email applications that exist outside of browsers that also make use of HTML/XHTML, in addition to some word processing software. Though the section does provide a good reverse engineering of browser technology, the section has little or nothing to do with HTML, in general. In addition, it also has little to do with the Document Object Model, which is based on the HTML syntax, not objects implemented by various browsers. Including this section greatly extends the HTML5 specification beyond the charter, and beyond boundaries one can reasonably expect from an effort focused on HTML, both the XML serialization and non-XML serialization, and the DOM. In addition, by focusing the specification primarily towards browsers, we are limiting the usefulness of the HTML specification for other uses, both now, and in the future for ebooks, as well as other new technologies. This is counter to good, technology practices. Consider how a programmer creates an application. They look for opportunities to create reusable objects, which they then use to create any number of applications, not just one. We should follow the same philosophy when creating a new version of HTML: restrict our effort to a new version of HTML, its serialization in XML, and the DOM. This will include new elements, such as video, which may not be useful for all variations of user agents, but the concept behind the new elements still fits within our perceptions of what we would reasonably expect from an HTML specification. Simplifying the HTML5 specification in this way will greatly increase its usability by many user agents, not just browsers. A standardized BOM (Browser Object Model) can reference the HTML, true, but so can other specifications, such as ePub (for eBooks) and so on. In addition, browser technology expands at a faster pace than that for the underlying HTML specification. By separating Section 6 out, it can then be incorporated into a new effort that can be focused specifically on the class of user agents, browsers. This new effort won't then be dependent on the same release cycle as HTML. I can see no negative ramifications from this change. Not only would it reduce the boundaries of the HTML5 specification to those that that one would reasonably expect, the separated section could then be used to seed a new, more targeted effort. As there is work on an ePub specification, there could also be work for the equivalent browser specification.
For reference, section 6 includes: - Rules for traversing a link (or other navigation) - Spec for the "DOM Level 0" Window (global) object - Definition of the same-origin security model - A description of how scripting and events work - Spec for timers - Spec for various prompt-related methods such as Window.alert - Spec for the "DOM Level 0" Navigator object - Spec for the Application Cache (which includes specific HTML syntax) - Definitions of the various link relations (such as rel="next" and rel="nofollow")
(In reply to comment #1) > For reference, section 6 includes: > > - Rules for traversing a link (or other navigation) > - Spec for the "DOM Level 0" Window (global) object > - Definition of the same-origin security model > - A description of how scripting and events work > - Spec for timers > - Spec for various prompt-related methods such as Window.alert > - Spec for the "DOM Level 0" Navigator object > - Spec for the Application Cache (which includes specific HTML syntax) > - Definitions of the various link relations (such as rel="next" and > rel="nofollow") > DOM Level 0 is a nickname, a reference to the Browser Object Model. It has existed separate from HTML for a decade. Most of the other items you reference are not specific to HTML, XHTML, or the DOM. Those aspects that are related specifically to HTML, XHTML, or the DOM, according to what we could reasonably expect, could be incorporated back into the document, into another, relevant section. Ask yourself something: is the DOM Level 0 necessary for ePub? For other non-browser applications? Are timers? Window.alert? Or are these specific needs for specific user agents?
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.
(In reply to comment #2) > DOM Level 0 is a nickname, a reference to the Browser Object Model. It has > existed separate from HTML for a decade. > > Most of the other items you reference are not specific to HTML, XHTML, or the > DOM. Those aspects that are related specifically to HTML, XHTML, or the DOM, > according to what we could reasonably expect, could be incorporated back into > the document, into another, relevant section. My list was provided for quick reference purposes, for anyone else reading the bug. > Ask yourself something: is the DOM Level 0 necessary for ePub? For other > non-browser applications? Are timers? Window.alert? Or are these specific needs > for specific user agents? > See my comments below based on Apple's experience building numerous non-browser HTML UAs, and supporting third-party developers in doing so.
(In reply to comment #4) > > See my comments below based on Apple's experience building numerous non-browser > HTML UAs, and supporting third-party developers in doing so. > I meant comments *above* not below.
(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.
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?
(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.) We've spent the last 10 years transforming the web browser from a document delivery language to an application deployment platform. It's been a messy process (to say the least), and up until now, it's happened on a largely ad hoc basis. HTML5 promises to create a proper set of rules to define how a web browser should behave, and advance the platform in a lot of really important ways, which is very good. Web development is, as a rule, terrible, and I'm thrilled to see progress towards a single coherent standard for browser behavior. 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.
(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.
(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.
(In reply to comment #9) > > 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. Most of that section is not specific to "applications". That being said, our charter scope includes support for both documents and 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. Thanks! > > 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. It looks like there is link traversal, navigation, and networking support, even if somewhat restricted. It looks like there are no frames or scripting. > > 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. Since ePub is defined as a subset of XHTML, it doesn't make sense to me to remove anything from the HTML5 spec on the basis that ePub doesn't need it. It's already a subset specification. > > 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. > It's true that there are different kinds of HTML clients. HTML5 provides for this with a variety of conformance classes: http://dev.w3.org/html5/spec/Overview.html#conformance-requirements It clearly says that non-scripting UAs are exempt from implementing any of the scripting features, for instance. The scripting features in section 6 don't look any different to me in this regard than other scripting- and event-related requirements throughout the spec. There doesn't seem to be explicit provision for HTML clients that support interaction, but never navigate (such as mail clients).
> It looks like there is link traversal, navigation, and networking support, even > if somewhat restricted. It looks like there are no frames or scripting. > I wouldn't include networking per se. > > > > 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. > > Since ePub is defined as a subset of XHTML, it doesn't make sense to me to > remove anything from the HTML5 spec on the basis that ePub doesn't need it. > It's already a subset specification. > I wouldn't remove any element of HTML because only one user agent uses only a subset. But I don't think user agents should impose their own unique requirements, either. > > > > 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. > > > > It's true that there are different kinds of HTML clients. HTML5 provides for > this with a variety of conformance classes: > http://dev.w3.org/html5/spec/Overview.html#conformance-requirements > There should be a simplified set of conformation requirements for all clients related to HTML, XHTML, and the DOM. > It clearly says that non-scripting UAs are exempt from implementing any of the > scripting features, for instance. The scripting features in section 6 don't > look any different to me in this regard than other scripting- and event-related > requirements throughout the spec. > Again, though, I don't think that we should be including application specific requirements into what should be a general markup language, and associated DOM. To be honest, we're in a real risk of never being able to be finished with HTML5 because we keep letting new requirements push out the scope. > There doesn't seem to be explicit provision for HTML clients that support > interaction, but never navigate (such as mail clients). >
(In reply to comment #12) > > > > Since ePub is defined as a subset of XHTML, it doesn't make sense to me to > > remove anything from the HTML5 spec on the basis that ePub doesn't need it. > > It's already a subset specification. > > > > I wouldn't remove any element of HTML because only one user agent uses only a > subset. But I don't think user agents should impose their own unique > requirements, either. I don't see anything specific to only one kind of client, but maybe you have some specific examples. > > > > > > > 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. > > > > > > > It's true that there are different kinds of HTML clients. HTML5 provides for > > this with a variety of conformance classes: > > http://dev.w3.org/html5/spec/Overview.html#conformance-requirements > > > > There should be a simplified set of conformation requirements for all clients > related to HTML, XHTML, and the DOM. Do you think there are any such clients not covered by one of the included conformance classes? > > > It clearly says that non-scripting UAs are exempt from implementing any of the > > scripting features, for instance. The scripting features in section 6 don't > > look any different to me in this regard than other scripting- and event-related > > requirements throughout the spec. > > > > Again, though, I don't think that we should be including application specific > requirements into what should be a general markup language, and associated DOM. None of the requirements are specific to only one kind of application, if that's what you mean. I believe I showed that all the subsections of section 6 apply to a wide variety of clients (though some may not apply to specific kinds of clients such as non-scripting UAs).
(In reply to comment #13) > (In reply to comment #12) > > > > > > Since ePub is defined as a subset of XHTML, it doesn't make sense to me to > > > remove anything from the HTML5 spec on the basis that ePub doesn't need it. > > > It's already a subset specification. > > > > > > > I wouldn't remove any element of HTML because only one user agent uses only a > > subset. But I don't think user agents should impose their own unique > > requirements, either. > > I don't see anything specific to only one kind of client, but maybe you have > some specific examples. > There is significant sections of the specification that have little to do with HTML, and mostly to do with browsers, or browser like objects. > > > > > > > > > > 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. > > > > > > > > > > It's true that there are different kinds of HTML clients. HTML5 provides for > > > this with a variety of conformance classes: > > > http://dev.w3.org/html5/spec/Overview.html#conformance-requirements > > > > > > > There should be a simplified set of conformation requirements for all clients > > related to HTML, XHTML, and the DOM. > > Do you think there are any such clients not covered by one of the included > conformance classes? > I think we're talking two different things here. You seem to think that if there are enough clients who use the technology, it's OK to include the technology in the HTML5 specification. What I'm saying is that regardless of how useful the technology is to various applications, if it's not specific to HTML, XHTML, or the DOM, then it is best handled in a separate specification. By separating the material, instead of one large, complex specification, with a confused sense of audience, we have two simple, lucid specifications, with a clear idea of audience. > > > > > It clearly says that non-scripting UAs are exempt from implementing any of the > > > scripting features, for instance. The scripting features in section 6 don't > > > look any different to me in this regard than other scripting- and event-related > > > requirements throughout the spec. > > > > > > > Again, though, I don't think that we should be including application specific > > requirements into what should be a general markup language, and associated DOM. > > None of the requirements are specific to only one kind of application, if > that's what you mean. I believe I showed that all the subsections of section 6 > apply to a wide variety of clients (though some may not apply to specific kinds > of clients such as non-scripting UAs). >
ePub is irrelevant to the question of removing stuff from the spec. The HTML WG is creating a spec for the Web. Parties who don't work on Web stuff are free to lower their R&D costs by reusing Web specs in non-Web contexts (e.g. offline browserless ebook readers). However, if a non-Web usage doesn't need something, it's no reason to remove that piece from a Web spec. (I'd also argue that the WG shouldn't add stuff in order to cater to non-Web use cases.) I think bugs of this flavor should be WONTFIXed, because they harm the goal of having the Open Web Platform well specified. (Having the stuff in *a* spec is more important than having the specs split according to anyone's particular spec-aesthetic preferences, IMO.)
(In reply to comment #15) > ePub is irrelevant to the question of removing stuff from the spec. The HTML WG > is creating a spec for the Web. Parties who don't work on Web stuff are free to > lower their R&D costs by reusing Web specs in non-Web contexts (e.g. offline > browserless ebook readers). However, if a non-Web usage doesn't need something, > it's no reason to remove that piece from a Web spec. The HTML WG is creating a spec for HTML and applications based on HTML. If non-Web usage doesn't need something, this *may* indicate that this feature is truly optional with respect to the design of the markup language HTML, and thus it's relevant input for the question on what the right granularity is for the set of specs we produce.
(In reply to comment #16) > The HTML WG is creating a spec for HTML and applications based on HTML. According to the Charter, the language deliverable of the group is "A language evolved from HTML4 for describing the semantics of documents and applications *on the World Wide Web*."(emphasis mine).
(In reply to comment #15) > ePub is irrelevant to the question of removing stuff from the spec. The HTML WG > is creating a spec for the Web. Parties who don't work on Web stuff are free to > lower their R&D costs by reusing Web specs in non-Web contexts (e.g. offline > browserless ebook readers). However, if a non-Web usage doesn't need something, > it's no reason to remove that piece from a Web spec. > > (I'd also argue that the WG shouldn't add stuff in order to cater to non-Web > use cases.) > > I think bugs of this flavor should be WONTFIXed, because they harm the goal of > having the Open Web Platform well specified. (Having the stuff in *a* spec is > more important than having the specs split according to anyone's particular > spec-aesthetic preferences, IMO.) > I use ePub as a demonstration of what can happen when a language is well designed. XHTML can not only can be used for web pages, it can also be used to create a entirely new version of book. This ability to expand beyond a basic set of parameters demonstrates what happens when you don't over-specify when creating a specification, and when you keep the content of the specification tightly focused on what it is supposed to be: HTML, XHTML, and the DOM. Rather than celebrate how the simplicity and elegance of XHTML 1.1 is vindicated in such use, you're seeing it as some lazy lack of R & D. That's not forward thinking because the ePub can be used for books accessed via the web, like I do when I check out my books from the library. Or if not ePub, some other use, which could occur over the web. Think of the specification in the context of a application rather than a spec. When you program, you modularize the application as much as possible. You do this because you want to reuse whatever bits can be reusable. You also keep your code tightly focused, to avoid scope creep. I imagine you've probably had a thing or two to say about non-programmers in the past who have asked for the kitchen sink in whatever application. And you've probably had to remind them that what they're asking for is out of scope. Just because HTML5 is a specification, not an application, doesn't mean we throw all of the good practices we've learned as technologist out the window. And the most critical good practice we're taught in college in comp-sci, is to avoid scope creep. To keep our creations clean, and focused.
(In reply to comment #17) > (In reply to comment #16) > > The HTML WG is creating a spec for HTML and applications based on HTML. > > According to the Charter, the language deliverable of the group is "A language > evolved from HTML4 for describing the semantics of documents and applications > *on the World Wide Web*."(emphasis mine). > Think of ePub as a perk. An example of a language done well. And the charter section you just described should have reminded you about what HTML5 is supposed to be: a language.
(In reply to comment #19) > (In reply to comment #17) > > (In reply to comment #16) > > > The HTML WG is creating a spec for HTML and applications based on HTML. > > > > According to the Charter, the language deliverable of the group is "A language > > evolved from HTML4 for describing the semantics of documents and applications > > *on the World Wide Web*."(emphasis mine). > > > > Think of ePub as a perk. An example of a language done well. > > And the charter section you just described should have reminded you about what > HTML5 is supposed to be: a language. > Per charter, the HTML WG's primary deliverable is supposed to specify language and associated APIs, for both documents and applications. Certainly there is no charter-based reason for removing a section of the spec because it contains mostly APIs which are mostly more useful for Web applications than Web documents.
(In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #17) > > > (In reply to comment #16) > > > > The HTML WG is creating a spec for HTML and applications based on HTML. > > > > > > According to the Charter, the language deliverable of the group is "A language > > > evolved from HTML4 for describing the semantics of documents and applications > > > *on the World Wide Web*."(emphasis mine). > > > > > > > Think of ePub as a perk. An example of a language done well. > > > > And the charter section you just described should have reminded you about what > > HTML5 is supposed to be: a language. > > > > Per charter, the HTML WG's primary deliverable is supposed to specify language > and associated APIs, for both documents and applications. Certainly there is no > charter-based reason for removing a section of the spec because it contains > mostly APIs which are mostly more useful for Web applications than Web > documents. > There is nothing in the charter, though, that the deliverables all have to be in one document. Or that every possible API for every possible application MUST be included. If this were true, this application will never be done. Charter or not, this section should never have been put into a document that purports to be the next version of HTML. A good technologist knows that you modularize your work, and that you keep the work focused.
With the removal of the Microdata section, the Browsers section is now Section 5. I've re-titled this bug.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: see diff given below Rationale: I've tried to find a compromise between the two points of view put forward in this bug I've split out the Web Browsers section from the "Core and Vocabulary" spec, and referenced it from the resulting Vocabulary spec. I also took the User Interaction section out along with the Web Browsers section, since it seemed to cover similar grounds thematically.
Checked in as WHATWG revision r4551. Check-in comment: Split out the Web Browsers section and related bits. http://html5.org/tools/web-apps-tracker?from=4550&to=4551
(In reply to comment #24) > Checked in as WHATWG revision r4551. > Check-in comment: Split out the Web Browsers section and related bits. > http://html5.org/tools/web-apps-tracker?from=4550&to=4551 > What is the Core and Vocabulary Spec? There is one specification: HTML5. What are you talking about?
Reopening this bug. The current split does not make the spec easier to read. There are far too many HTML specific parts in the Core spec to make it significantly more reusable. It further doesn't reduce the amount of specification text that anyone wanting to understand HTML has to read since you still are forced to read both the Vocabulary spec as well as the Core spec. I still support the idea of having parts that aren't HTML specific (like Window/History/browsing contexts etc) split into a separate spec. However the current split is not that. And until we have a good split I think we are causing more harm than help by creating a split.
After some review and reflection, I tend to agree with Jonas that the current Core/Vocabulary split is not very helpful (though I am ok with the other recent splits).
I don't see any other way to address this bug that makes sense, so unless anyone has any ideas, I guess I'll put it back the way it was.
Checked in as WHATWG revision r4553. Check-in comment: Merge core and vocab specs back together. http://html5.org/tools/web-apps-tracker?from=4552&to=4553
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: I have put the spec back to what it was like before, because the proposed change was found to be significantly less popular and no alternative compromise has been proposed.
(In reply to comment #30) > EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are > satisfied with this response, please change the state of this bug to CLOSED. If > you have additional information and would like the editor to reconsider, please > reopen this bug. If you would like to escalate the issue to the full HTML > Working Group, please add the TrackerRequest keyword to this bug, and suggest > title and text for the tracker issue; or you may create a tracker issue > yourself, if you are able to do so. For more details, see this document: > http://dev.w3.org/html5/decision-policy/decision-policy.html > > Status: Rejected > Change Description: no spec change > Rationale: I have put the spec back to what it was like before, because the > proposed change was found to be significantly less popular and no alternative > compromise has been proposed. > As an editorial comment, I want to link in the following: http://lastweekinhtml5.blogspot.com/2010/01/html5-sabotage.html I have also created a tracker issue for this item: http://www.w3.org/html/wg/tracker/issues/94
Please do not link to scatological trollblogs in bugzilla.
(In reply to comment #32) > Please do not link to scatological trollblogs in bugzilla. > Frankly, that post spoke for itself. And Maciej, stop telling me what to do. Go be paternal with someone else.