Re: ISSUE-94 Change Proposal

Thanks for providing a Change Proposal for this issue! The chairs  are  
reviewing Change Proposals to ensure that they meet the required  
structure. Here is our feedback on this Change Proposal:

(1) This Change Proposal includes all of the required sections with  
appropriate content.

(2) The Details section does not contain sufficient detail. The level  
of detail must be sufficient that the changes can be applied without  
ambiguity. Instead, the Change Proposal suggests how others could do  
the work to determine the details of the change, and concedes that  
this would be a lot of work with many alternative options.

We suggest updating the Change Proposal to reflect the feedback in  
point (2). If no one indicates a willingness to update this Change  
Proposal with full details by April 13, then the issue will be closed  
without prejudice. This does not preclude anyone from coming forward  
with a complete Change Proposal at a later time, or from simply  
proposing a new draft with the material to be split at a later time.

Regards,
Maciej



On Mar 31, 2010, at 6:24 AM, Shelley Powers wrote:

> Summary
>
>    Split the material related to the browsing context into a separate
> specification, reducing the existing HTML5 specification to covering
> HTML, XHTML, and the DOM, only.
>
> Rationale
>
> The following is my initial request that led to this issue[1]
>
>
>    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.
>
>
> The end result of this request was a odd sequence of events where the
> HTML5 Editor split apart the W3C version of the HTML5 specification,
> but not specifically along browsing context line. This is also when
> the WhatWG version of the HTML5 specification began to strongly
> diverge from the W3C version.
>
> The split apart parts were put back together again, but then the
> original Section 6 was split into two sections, Section 5 and 6. No
> rationale was given for not meeting my request, so I can't reproduce
> here.
>
> The concept of a Browser Object Model is not new. If you search on the
> term, you'll find hundreds of references, including discussion about
> how it, unlike the DOM, is not defined within any formal
> specification. A formal specification is needed, though, and I agree
> with the work begun in this group. I just don't believe that the HTML5
> specification is the place for this work, because the BOM, which
> includes objects like Window, History, Navigator, Timers, and so on,
> is not specific to HTML, XHTML, or the DOM. SVG is also dependent on
> the BOM, as is any script enabled document that could potentially be
> opened in a browser-like object.
>
> Splitting out the non-HTML/XHTML/DOM bits isn't going to be easy,
> because there's a great deal of interwoven coverage of these items all
> throughout the specification. We could make the split based on
> script-enabled agent versus not, but this doesn't make a lot of sense
> if the DOM is a valid component of the HTML5 specification. A split
> along the lines of requirements for scripting-enabled user agents, as
> compared to all user agents, is also not a matter of moving a couple
> of sections. For instance, in Section 3, titled Semantics, Structure,
> and APIs of all HTML documents, subsection 3.1.2 states:
>
> "User agents must raise a SECURITY_ERR  exception whenever any of the
> members of an HTMLDocument  object are accessed by scripts whose
> effective script origin is not the same as the Document's effective
> script origin."
>
> It is obvious that such a stricture is targeted solely to those user
> agents that support scripting, and is completely and totally
> irrelevant for those that don't. This makes this stricture a good
> candidate for removal to the separate scripting User Agent document,
> yet isn't in the target sections first referenced in the bug and
> issue.
>
> In addition, it references HTMLDocument, which is part of the DOM,
> though the behavior is more specific to browsing context. This
> demonstrates how carefully a split will need to be made, with some
> sections needing more in-depth discussions than others, about whether
> to split out, or not.
>
> Why does it matter to do this kind of split? Because the more
> unrelated material non-scripted user agents have to wade through to
> find their relevant bits, the more likely they'll miss something
> important because it's entangled with all sorts of browser or other
> user agent specific instructions. Conversely, burying browser context
> material in with HTML makes the material harder for user agents to
> update, and may hide this crucial information from web page
> developers, who aren't expecting this type of information to be
> included in an HTML specification.
>
> An additional, and significant concern is that many of the
> specifications related to the browsing context aren't specific to just
> HTML/XHTML. They can also apply to other document types, such as SVG,
> MathML, and whatever the future brings. It's not appropriate to tie
> what amounts to browser behavior to one document type.
>
> I don't think this type of split would be contentious, but I do think
> it will be a lot of work. It is definitely a group effort.
>
> Details
>
> OK, I've listed out the problem. Now what is a solution?
>
> Rather than split the document based on whether the user agent is
> script-enabled or not, look for material relevant to the browsing
> context, whether stated or not, and mark it as a potential candidate
> for movement to a separate document. Once all are marked, then it's a
> matter of determining whether the section should be split or not.
> That's where the group effort comes in, because frankly, the more the
> relevant audience is involved, the better job it will be.
>
> This work does amount to a major refacturing of the HTML5
> specification. However, after so many changes in the last year, so
> many components split out, and the ongoing discussions about whether
> author guidelines should be included or not, the specification is
> overdue for this type of operation.  You don't have to spend too many
> hours going through the document to see the fragmented nature of the
> material, and that a good, solid edit is needed. Sometimes it is
> better for progress to stop, look, and think, rather than continually
> move ahead.
>
> I didn't have the time to go through the  many pages of the HTML5
> specification, but did go through Sections 5 and 6, in the March 4th
> published HTML5 spec. The following list of candidate items is not by
> any measure complete or comprehensive, but it is a start.
>
>
>    * Section 5.1 on browsing contexts. Much of this material is
> Window related, and I feel comfortable that this section can be split,
> in its entirety. Reworded, this could become an intro for a new
> document. It does need some clean up, as it jumps about, and the text
> is a little hard to follow. Some collapsing of multiple sentences into
> paragraphs, rather than one sentence-one paragraph could help the
> readability.
>
>    * Section 5.2 on the Window object. This one is an excellent
> candidate, and is relatively easy to follow, so shouldn't need much in
> the way of editing.
>
>    * Section 5.3 on Origin. There's nothing about the origin that's
> pertinent to HTML, XHTML, or even the DOM. It's really specific to the
> location, and security based on the location, which is outside the
> scope of markup or a Document Object Model. It is important material,
> but would be best served in the separate document. For instance, I
> would say there's much in this section that would be relevant to an
> SVG document.
>
>    * Section 5.4 on Session history and navigation. Again, another
> excellent candidate for removal to the new document.
>
>    * Section 5.5 on Browsing the Web. Even without the title, you can
> tell that this section is a particularly strong candidate for removal
> to the new document. I have to question, though, the number of
> algorithms given in the text in this and other sections: are these
> really so necessary? Or are we really overspecifying, which can be
> just as harmful as underspecifying? This might be a question to ask
> when doing this split. There are also discussions of events, that
> could be considered borderline for movement, but the events really are
> related to the browsing context, not necessarily the HTML/XHTML/DOM.
> It might be best to define the actions and events in the separate
> document, and then ensure the section is referenced in the HTML5
> specification.
>
>    * Section 5.6 on Offline Web Applications. This is another that's
> a given. There's nothing about HTML, XHTML, or the DOM that is
> application specific. Something like offline web application cache is
> specific to the browsing context, not the markup or the object model.
> This is also the last subsection in Section 5, so all of Section 5
> could be moved, with appropriate back and forth links, and editing of
> the moved material.
>
>    * Section 6.1 on Scripting should be a candidate, though this move
> might require minor tweaking. There are references to DOM methods that
> probably should be pulled out of the moved material and incorporated
> into the HTML5 spec. Either that, or removed as unnecessary, since
> these methods are defined in another W3C document. There is a section
> on event handlers, but most of the section is focused on how the user
> agent should process the event, not on how the event handler is
> defined within HTML. The event handler section could potentially be
> split, part to the browsing context document, part to remain in the
> HTML5 spec. Also again, there does seem to be a great deal of
> overspecification in this section, but perhaps it is necessary.
>
>    * Section 6.2 on Timers. Oh, most definitely split to the browsing
> context document. We know this is just as pertinent to SVG as HTML.
>
>    * Section 6.3 on User Prompts. Again, a good candidate, as
> relevant for SVG as HTML.
>
>    * Section 6.4 on System state and capabilities is really about the
> Navigator object, and is definitely part of the browsing context. And
> this is the last subsection in Section 6, so this section could be
> moved. Again, there is some editing that needs to be done, and
> cross-reference links.
>
>
> My first inclination was also to include Section 7.10 on the Undo
> History, but this section is related to the DOM. However, Section 7.8
> on Spelling and Grammar checking should also be moved. The object
> referenced is the document object but the usage is pure browsing
> context. I also think Section 7.9 on Drag and Drop could be a
> potential candidate for movement. I don't want to lose the section,
> but I think it fits within the domain of "browsing context" more aptly
> than in the domain labeled "HTML/XHTML/DOM". Hard to say.
>
> Section 7.11, the Editing APIs is a tough one. It is definitely
> specific to browsing context, especially in the examples, but the
> document object is the focus. I think the better way of looking at
> this is, if the section is more pertinent to interacting with agents
> outside the page, then it probably better fits within the browsing
> context. If this is for toolbars and extensions, then it definitely
> does work better in browsing context.
>
> There are other sections, but this is a start, and I've run out of
> time to go more in-depth into the document.
>
> Though I'm a big believer in doing business on the email list, I
> strongly believe this activity would be better done at a face to face
> meeting, including all of the browser companies, at a minimum. This
> is, in a way, the browsing company's business model.
>
> Impact
>
> Positive
>
> As painful as the amount of work seems, we would have a superior set
> of documents as a result. If we move the browsing context to a
> separate document, it would decrease the size of the HTML5
> specification, but also focus the audience within the newly separated
> document. If we were to further split out authoring guidelines, and
> refocus the HTML5 specification purely on HTML, XHTML, and the DOM,
> we'd also be ahead, but that's outside the scope of this effort.
>
> This type of major movement is also an excellent time to do a general
> readability edit— to ensure a consistent audience focus in each
> section, and to work on the flow. We can get so caught up on stating
> rules that we end up overwhelming the reader, even a highly technical
> reader. When we do, they will unconsciously tune out the flood of
> rules, and could miss very important data. We need to pad the shotgun
> effect that some of the sections have, where all the rules are
> given--bang, bang, bang!--one after another in a continue stream of
> one sentence paragraphs, one rule per sentence. We need to flesh this
> material out. so that the reader can comfortably read through the
> section without becoming overwhelmed.
>
> Negative
>
> Time. This is a major work, though it doesn't have to be an
> overwhelming work. If the group participates in the exercise, the work
> can be split among many. In addition, a face-to-face could easily work
> through some of the more problematical areas.
>
> I have a feeling that in the end, the specification will progress more
> swiftly making this move, than not.
>
> Risks
>
> This is a major work, and we're already a relatively burned out group.
> I think, though, a smaller task group, consisting primarily of reps
> from the browsing companies, and _some_ members from the other
> communities, could progress quickly with this task. I do not think it
> needs day to day oversight by the larger group.
>
> References
>
>
> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8365
>
>
> ------
>
> Shelley Powers
> http://realtech.burningbird.net
>

Received on Tuesday, 6 April 2010 20:17:35 UTC