WHATWG Wiki - User contributions [en]

HTTP

2012-10-17T08:45:42Z

Aryeh Gregor: /* Assume Vary: User-Agent */ This doesn't make sense

This page is an attempt to document some discrepancies between browsers and RFC 2616 (and its successor, RFC 2616) because the HTTP WG seems unwilling to resolve those issues. Hopefully one day someone writes HTTP5 and takes this into account.

== Redirects ==

For 301 and 302 redirects browsers uniformly ignore HTTP and use GET for the subsequent request if the initial request uses an unsafe method. (And the user is not prompted.)

'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/thread.html#msg225

== Location header ==

Browsers handle relative URIs and URIs with invalid characters in interoperable fashion.

'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/thread.html#msg276

== Content-Location header ==

Browsers cannot support this header.

'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/thread.html#msg190

This has apparently been fixed by making Content-Location have no UA conformance criteria. (It's not clear what it's good for at this point.)

== Accept header ==

Accept header should preferably be done without spaces.

(not raised, odinho: I came across a site that didn't like the spaces, the developer said he'd gotten it off php.net or stackoverflow. He fixed the site. This could be disputed.)

== Requiring two interoperable browser implementations ==

To proof that RFC 2616 can be implemented there should be two compatible implementations in browsers.

'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/0222.html

== Assume Vary: User-Agent ==

UAs and intermediary caches should act as if all responses had Vary: User-Agent specified since many pages on the Web serve different content depending on the User-Agent header but do not bother specifying Vary: User-Agent.

'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0114.html

:You may as well not have a cache if you do this. It's hard to find two users with the same User-Agent string if you try. It varies based on minor browser version, major OS version, and in old IE doesn't it vary based on installed plugins? Yes, some pages will break if you run a transparent caching proxy and don't vary based on UA, but it will be a small minority and somewhat random, and generally they'll fix themselves if you force-refresh. (Browsers send Cache-Control: no-cache when you force-refresh, which will skip a normally-configured cache.) Even if you vary based on UA, caching proxies will break some pages, because some sites serve incorrect caching headers and a caching proxy will make you hit these more often even in the single-user case. (E.g., hitting refresh will skip browser cache for the current page but not proxy cache, right?)So basically, this is a performance vs. correctness tradeoff, and the correct answer for the vast majority of users is not to have a caching proxy at all. Some will want a caching proxy that serves them some incorrect pages. No one wants a caching proxy that varies based on UA, because then the cache will be useless. The only case I could think of where this might make sense is in an office with a homogeneous browser environment, which wants caching for its standard browsers (which all have the same UA string), but still wants to be relatively correct for people using Wi-Fi on their laptops with different browsers. But it's not something that makes any sense to require across the board. [[User:Aryeh Gregor|Aryeh Gregor]] 08:45, 17 October 2012 (UTC)

[[Category:Spec_coordination]]

Editing use-cases

2012-01-26T17:10:32Z

Aryeh Gregor: Create page

This is a page to document use-cases for editing that are not well served by the current contenteditable feature as specced or implemented.

Interesting link: http://www.mediawiki.org/wiki/Special:VisualEditorSandbox

Initial version of this page is thanks to feedback from Roan Kattouw and Trevor Parscal of Wikimedia.

== An atomic chunk of HTML ==
'''Use-case:''' A Wikipedia page has embedded templates or other data with special meaning, such as a reference or a "[citation needed]" link. It must not be possible for the user to place the cursor inside the chunk of HTML, or to modify it internally in any way. If the user attempts to move, copy, or delete the chunk of HTML, the author must be allowed to decide what happens.

'''Solution:''' The chunk of HTML should be marked contenteditable=false. Per spec, this will not allow it to be modified or deleted, but will let it be moved. But more features are needed for authors to be able to control moving, copying, and deleting. For instance, it might be desirable to let it be deleted if the author backspaces over it. It might also be desirable to specify special behavior if it's copied.

UndoManager Problem Descriptions

2011-11-07T20:24:09Z

Aryeh Gregor: /* Collaborative editing */ Update requirement to leave it up in the air

Use-cases from [http://rniwa.com/editing/undomanager-usecases.html rniwa's page] and [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-October/033630.html a whatwg thread], patterned after [[Microdata Problem Descriptions]].

General principles:

* Try to make every use-case as easy as possible to deal with. Don't make the common use-cases harder for the sake of allowing rarer use-cases.
* Don't allow any functionality that isn't required by a use-case. This adds complexity for no clear reason. If a use-case we didn't think of comes up later, add new functionality then, when we know exactly what we're looking for.

== Managing DOM changes ==

'''Scenarios:'''

* A site wants to allow adding a special type of site-specific markup, say .
* A rich text editor provides a source code view that lets users edit HTML directly. In such an app, going to a source code view, edit HTML, and coming back to WYSIWYG view should be treated as one editing operation.
* A code editor that implements auto-completion should be able to use user agent's undo transaction history.

'''Requirements:'''

* It must be possible to associate a set of DOM changes with a custom entry in the undo history. The changes might be to non-editable areas.
* The author must have control over exactly what appears in the undo history. It must be possible to have multiple different DOM changes be one undo history entry, or multiple ones, with customizable labels.
* The author should have to do no special work to undo the action. The UA should track and undo the DOM changes just like for any command.
* Nothing in these use-cases requires that the author be able to specify any special action to be taken on undo/redo. All relevant state is in the DOM, or could be put in the DOM, so the UA can automatically handle undo/redo.

== Separate undo histories ==

'''Scenarios:'''

* A rich text editor has a widget to draw a vector-based illustration. The user should be able to open the widget and modify the illustration while leaving the undo transaction history of the main editor intact.

'''Requirements:'''

* The undo history for the vector image must not be intermixed with the undo history for the rest of the page.

== Non-DOM state ==

'''Scenarios:'''

* A canvas-based drawing app that uses server-side storage. Such an application should provide undo and redo menu items on the user agent's native UI.

'''Requirements:'''

* It must be possible for the author to track non-DOM state (such as canvas operations) in addition to just DOM state.
* It must be possible for the author to run arbitrary JavaScript, such as XHR, on apply/unapply/reapply of a transaction.
* DOM state should still be controlled by the UA. Nothing in the use-case implies that the author wants to make any DOM changes that aren't undone/redone like any other DOM changes. The author must not be forced to deal with manually handling DOM state just because they want to handle non-DOM state.

== Collaborative editing ==

'''Scenarios:'''

* Real-time syncing of rich-text edited data with simultaneous multi-user editing. Data pulled in from other users should modify the DOM, but not be included in the undo history. When a user tries to undo something, it needs to undo only that user's changes, using some type of intelligent merge algorithm.
* Collaborative editing of non-rich-text things, such as canvas, as in the previous use-cases.

'''Requirements:'''

* The author must be able to decide exactly how undo/redo are executed if they so choose. They might want to use application-specific heuristics to undo changes when there are conflicts.
* If browsers try to merge changes themselves, the algorithm should be well-defined if possible. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results. '''Issue:''' Is this doable? Refer to mailing list discussion.
* It must be possible to have some parts of the page author-controlled, and some parts of the page UA-controlled. For instance, there might be a collaborative editor on the same page as some unrelated inputs.
* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the parts of the page that are collaboratively edited, there is no reason for the UA to make any automatic DOM changes at all.

== Author-managed UI ==

'''Scenarios:'''

* A standard rich-text editor with various buttons and drop-downs. Undo/redo should not automatically affect any of the UI's state. E.g., if the user selects "red" in the color drop-down, undo should not change it back to the previous selection.
* A slideshow app. There are multiple slides, each of which contains some editable content. The user is allowed to do rich-text editing on the slides using contenteditable, but also take other actions like adding or removing slides. There is UI that gives a list of slides, and some user actions will modify it (such as adding or removing a slide). However, some actions that are not tracked by undo/redo might also modify the UI, such as moving to the next or previous slide.

'''Requirements:'''

* The browser must not touch the UI parts of the page, but still has to fully manage the non-UI parts.
* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the UI parts of the page, there is no reason for the UA to make any automatic DOM changes at all.

UndoManager Problem Descriptions

2011-11-07T20:07:07Z

Aryeh Gregor: Update one requirement with a key clarification

Use-cases from [http://rniwa.com/editing/undomanager-usecases.html rniwa's page] and [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-October/033630.html a whatwg thread], patterned after [[Microdata Problem Descriptions]].

General principles:

* Try to make every use-case as easy as possible to deal with. Don't make the common use-cases harder for the sake of allowing rarer use-cases.
* Don't allow any functionality that isn't required by a use-case. This adds complexity for no clear reason. If a use-case we didn't think of comes up later, add new functionality then, when we know exactly what we're looking for.

== Managing DOM changes ==

'''Scenarios:'''

* A site wants to allow adding a special type of site-specific markup, say .
* A rich text editor provides a source code view that lets users edit HTML directly. In such an app, going to a source code view, edit HTML, and coming back to WYSIWYG view should be treated as one editing operation.
* A code editor that implements auto-completion should be able to use user agent's undo transaction history.

'''Requirements:'''

* It must be possible to associate a set of DOM changes with a custom entry in the undo history. The changes might be to non-editable areas.
* The author must have control over exactly what appears in the undo history. It must be possible to have multiple different DOM changes be one undo history entry, or multiple ones, with customizable labels.
* The author should have to do no special work to undo the action. The UA should track and undo the DOM changes just like for any command.
* Nothing in these use-cases requires that the author be able to specify any special action to be taken on undo/redo. All relevant state is in the DOM, or could be put in the DOM, so the UA can automatically handle undo/redo.

== Separate undo histories ==

'''Scenarios:'''

* A rich text editor has a widget to draw a vector-based illustration. The user should be able to open the widget and modify the illustration while leaving the undo transaction history of the main editor intact.

'''Requirements:'''

* The undo history for the vector image must not be intermixed with the undo history for the rest of the page.

== Non-DOM state ==

'''Scenarios:'''

* A canvas-based drawing app that uses server-side storage. Such an application should provide undo and redo menu items on the user agent's native UI.

'''Requirements:'''

* It must be possible for the author to track non-DOM state (such as canvas operations) in addition to just DOM state.
* It must be possible for the author to run arbitrary JavaScript, such as XHR, on apply/unapply/reapply of a transaction.
* DOM state should still be controlled by the UA. Nothing in the use-case implies that the author wants to make any DOM changes that aren't undone/redone like any other DOM changes. The author must not be forced to deal with manually handling DOM state just because they want to handle non-DOM state.

== Collaborative editing ==

'''Scenarios:'''

* Real-time syncing of rich-text edited data with simultaneous multi-user editing. Data pulled in from other users should modify the DOM, but not be included in the undo history. When a user tries to undo something, it needs to undo only that user's changes, using some type of intelligent merge algorithm.
* Collaborative editing of non-rich-text things, such as canvas, as in the previous use-cases.

'''Requirements:'''

* The author must be able to decide exactly how undo/redo are executed if they so choose. They might want to use application-specific heuristics to undo changes when there are conflicts.
* If browsers try to merge changes themselves, the algorithm should be well-defined if possible. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results. However, this might be impossible to attain, because authors can always make DOM changes outside of any transaction, and thereby mess everything up.
* It must be possible to have some parts of the page author-controlled, and some parts of the page UA-controlled. For instance, there might be a collaborative editor on the same page as some unrelated inputs.
* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the parts of the page that are collaboratively edited, there is no reason for the UA to make any automatic DOM changes at all.

== Author-managed UI ==

'''Scenarios:'''

* A standard rich-text editor with various buttons and drop-downs. Undo/redo should not automatically affect any of the UI's state. E.g., if the user selects "red" in the color drop-down, undo should not change it back to the previous selection.
* A slideshow app. There are multiple slides, each of which contains some editable content. The user is allowed to do rich-text editing on the slides using contenteditable, but also take other actions like adding or removing slides. There is UI that gives a list of slides, and some user actions will modify it (such as adding or removing a slide). However, some actions that are not tracked by undo/redo might also modify the UI, such as moving to the next or previous slide.

'''Requirements:'''

* The browser must not touch the UI parts of the page, but still has to fully manage the non-UI parts.
* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the UI parts of the page, there is no reason for the UA to make any automatic DOM changes at all.

UndoManager Problem Descriptions

2011-11-07T19:39:48Z

Aryeh Gregor: More adjustment

Use-cases from [http://rniwa.com/editing/undomanager-usecases.html rniwa's page] and [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-October/033630.html a whatwg thread], patterned after [[Microdata Problem Descriptions]].

General principles:

* Try to make every use-case as easy as possible to deal with. Don't make the common use-cases harder for the sake of allowing rarer use-cases.
* Don't allow any functionality that isn't required by a use-case. This adds complexity for no clear reason. If a use-case we didn't think of comes up later, add new functionality then, when we know exactly what we're looking for.

== Managing DOM changes ==

'''Scenarios:'''

* A site wants to allow adding a special type of site-specific markup, say .
* A rich text editor provides a source code view that lets users edit HTML directly. In such an app, going to a source code view, edit HTML, and coming back to WYSIWYG view should be treated as one editing operation.
* A code editor that implements auto-completion should be able to use user agent's undo transaction history.

'''Requirements:'''

* It must be possible to associate a set of DOM changes with a custom entry in the undo history. The changes might be to non-editable areas.
* The author must have control over exactly what appears in the undo history. It must be possible to have multiple different DOM changes be one undo history entry, or multiple ones, with customizable labels.
* The author should have to do no special work to undo the action. The UA should track and undo the DOM changes just like for any command.
* Nothing in these use-cases requires that the author be able to specify any special action to be taken on undo/redo. All relevant state is in the DOM, or could be put in the DOM, so the UA can automatically handle undo/redo.

== Separate undo histories ==

'''Scenarios:'''

* A rich text editor has a widget to draw a vector-based illustration. The user should be able to open the widget and modify the illustration while leaving the undo transaction history of the main editor intact.

'''Requirements:'''

* The undo history for the vector image must not be intermixed with the undo history for the rest of the page.

== Non-DOM state ==

'''Scenarios:'''

* A canvas-based drawing app that uses server-side storage. Such an application should provide undo and redo menu items on the user agent's native UI.

'''Requirements:'''

* It must be possible for the author to track non-DOM state (such as canvas operations) in addition to just DOM state.
* It must be possible for the author to run arbitrary JavaScript, such as XHR, on apply/unapply/reapply of a transaction.
* DOM state should still be controlled by the UA. Nothing in the use-case implies that the author wants to make any DOM changes that aren't undone/redone like any other DOM changes. The author must not be forced to deal with manually handling DOM state just because they want to handle non-DOM state.

== Collaborative editing ==

'''Scenarios:'''

* Real-time syncing of rich-text edited data with simultaneous multi-user editing. Data pulled in from other users should modify the DOM, but not be included in the undo history. When a user tries to undo something, it needs to undo only that user's changes, using some type of intelligent merge algorithm.
* Collaborative editing of non-rich-text things, such as canvas, as in the previous use-cases.

'''Requirements:'''

* The author must be able to decide exactly how undo/redo are executed if they so choose. They might want to use application-specific heuristics to undo changes when there are conflicts.
* If browsers try to merge changes themselves, the algorithm must be well-defined. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results.
* It must be possible to have some parts of the page author-controlled, and some parts of the page UA-controlled. For instance, there might be a collaborative editor on the same page as some unrelated inputs.
* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the parts of the page that are collaboratively edited, there is no reason for the UA to make any automatic DOM changes at all.

== Author-managed UI ==

'''Scenarios:'''

* A standard rich-text editor with various buttons and drop-downs. Undo/redo should not automatically affect any of the UI's state. E.g., if the user selects "red" in the color drop-down, undo should not change it back to the previous selection.
* A slideshow app. There are multiple slides, each of which contains some editable content. The user is allowed to do rich-text editing on the slides using contenteditable, but also take other actions like adding or removing slides. There is UI that gives a list of slides, and some user actions will modify it (such as adding or removing a slide). However, some actions that are not tracked by undo/redo might also modify the UI, such as moving to the next or previous slide.

'''Requirements:'''

* The browser must not touch the UI parts of the page, but still has to fully manage the non-UI parts.
* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the UI parts of the page, there is no reason for the UA to make any automatic DOM changes at all.

UndoManager Problem Descriptions

2011-11-07T19:33:42Z

Aryeh Gregor: Refine one of the use-cases

Use-cases from [http://rniwa.com/editing/undomanager-usecases.html rniwa's page] and [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-October/033630.html a whatwg thread], patterned after [[Microdata Problem Descriptions]].

General principles:

* Try to make every use-case as easy as possible to deal with. Don't make the common use-cases harder for the sake of allowing rarer use-cases.
* Don't allow any functionality that isn't required by a use-case. This adds complexity for no clear reason. If a use-case we didn't think of comes up later, add new functionality then, when we know exactly what we're looking for.

== Managing DOM changes ==

'''Scenarios:'''

* A site wants to allow adding a special type of site-specific markup, say .
* A rich text editor provides a source code view that lets users edit HTML directly. In such an app, going to a source code view, edit HTML, and coming back to WYSIWYG view should be treated as one editing operation.
* A code editor that implements auto-completion should be able to use user agent's undo transaction history.

'''Requirements:'''

* It must be possible to associate a set of DOM changes with a custom entry in the undo history. The changes might be to non-editable areas.
* The author must have control over exactly what appears in the undo history. It must be possible to have multiple different DOM changes be one undo history entry, or multiple ones, with customizable labels.
* The author should have to do no special work to undo the action. The UA should track and undo the DOM changes just like for any command.
* Nothing in these use-cases requires that the author be able to specify any special action to be taken on undo/redo. All relevant state is in the DOM, or could be put in the DOM, so the UA can automatically handle undo/redo.

== Separate undo histories ==

'''Scenarios:'''

* A rich text editor has a widget to draw a vector-based illustration. The user should be able to open the widget and modify the illustration while leaving the undo transaction history of the main editor intact.

'''Requirements:'''

* The undo history for the vector image must not be intermixed with the undo history for the rest of the page.

== Non-DOM state ==

'''Scenarios:'''

* A canvas-based drawing app that uses server-side storage. Such an application should provide undo and redo menu items on the user agent's native UI.

'''Requirements:'''

* It must be possible for the author to track non-DOM state (such as canvas operations) in addition to just DOM state.
* It must be possible for the author to run arbitrary JavaScript, such as XHR, on apply/unapply/reapply of a transaction.
* DOM state should still be controlled by the UA. Nothing in the use-case implies that the author wants to make any DOM changes that aren't undone/redone like any other DOM changes. The author must not be forced to deal with manually handling DOM state just because they want to handle non-DOM state.

== Full custom control of DOM state ==

'''Scenarios:'''

* Real-time syncing of rich-text edited data with simultaneous multi-user editing. Data pulled in from other users should modify the DOM, but not be included in the undo history. When a user tries to undo something, it needs to undo only that user's changes, using some type of intelligent merge algorithm.
* Collaborative editing of non-rich-text things, such as canvas, as in the previous use-cases.
* A slideshow app. There are multiple slides, each of which contains some editable content. The user is allowed to do rich-text editing on the slides using contenteditable, but also take other actions like adding or removing slides. There is UI that gives a list of slides, and some user actions will modify it (such as adding or removing a slide). However, some actions that are not tracked by undo/redo might also modify the UI, such as moving to the next or previous slide.

'''Requirements:'''

* The author must be able to decide exactly how undo/redo are executed if they so choose. They might want to use application-specific heuristics to undo changes when there are conflicts.
* If browsers try to merge changes themselves, the algorithm must be well-defined. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results.
* It must be possible to have some parts of the page author-controlled, and some parts of the page UA-controlled. For instance, there might be a collaborative editor on the same page as some unrelated inputs. Likewise for the slideshow app.
* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the parts of the page that are collaboratively edited, there is no reason for the UA to make any automatic DOM changes at all.

UndoManager Problem Descriptions

2011-11-07T19:27:31Z

Aryeh Gregor: Complete an unfinished sentence

Use-cases from [http://rniwa.com/editing/undomanager-usecases.html rniwa's page] and [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-October/033630.html a whatwg thread], patterned after [[Microdata Problem Descriptions]].

General principles:

* Try to make every use-case as easy as possible to deal with. Don't make the common use-cases harder for the sake of allowing rarer use-cases.
* Don't allow any functionality that isn't required by a use-case. This adds complexity for no clear reason. If a use-case we didn't think of comes up later, add new functionality then, when we know exactly what we're looking for.

== Managing DOM changes ==

'''Scenarios:'''

* A site wants to allow adding a special type of site-specific markup, say .
* A slideshow app. There are multiple slides, each of which contains some editable content. The user is allowed to do rich-text editing on the slides using contenteditable, but also take other actions like adding or removing slides. All changes are either in the DOM, or could be stored in the DOM (using data-* or such).
* A rich text editor provides a source code view that lets users edit HTML directly. In such an app, going to a source code view, edit HTML, and coming back to WYSIWYG view should be treated as one editing operation.
* A code editor that implements auto-completion should be able to use user agent's undo transaction history.

'''Requirements:'''

* It must be possible to associate a set of DOM changes with a custom entry in the undo history. The changes might be to non-editable areas.
* The author must have control over exactly what appears in the undo history. It must be possible to have multiple different DOM changes be one undo history entry, or multiple ones, with customizable labels.
* The author should have to do no special work to undo the action. The UA should track and undo the DOM changes just like for any command.
* Nothing in these use-cases requires that the author be able to specify any special action to be taken on undo/redo. All relevant state is in the DOM, or could be put in the DOM, so the UA can automatically handle undo/redo.

== Separate undo histories ==

'''Scenarios:'''

* A rich text editor has a widget to draw a vector-based illustration. The user should be able to open the widget and modify the illustration while leaving the undo transaction history of the main editor intact.

'''Requirements:'''

* The undo history for the vector image must not be intermixed with the undo history for the rest of the page.

== Non-DOM state ==

'''Scenarios:'''

* A canvas-based drawing app that uses server-side storage. Such an application should provide undo and redo menu items on the user agent's native UI.

'''Requirements:'''

* It must be possible for the author to track non-DOM state (such as canvas operations) in addition to just DOM state.
* It must be possible for the author to run arbitrary JavaScript, such as XHR, on apply/unapply/reapply of a transaction.
* DOM state should still be controlled by the UA. Nothing in the use-case implies that the author wants to make any DOM changes that aren't undone/redone like any other DOM changes. The author must not be forced to deal with manually handling DOM state just because they want to handle non-DOM state.

== Custom control of DOM state ==

'''Scenarios:'''

* Real-time syncing of rich-text edited data with simultaneous multi-user editing. Data pulled in from other users should modify the DOM, but not be included in the undo history. When a user tries to undo something, it needs to undo only that user's changes, using some type of intelligent merge algorithm.
* Collaborative editing of non-rich-text things, such as canvas, as in the previous use-cases.

'''Requirements:'''

* The author must be able to decide exactly how undo/redo are executed if they so choose. They might want to use application-specific heuristics to undo changes when there are conflicts.
* If browsers try to merge changes themselves, the algorithm must be well-defined. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results.
* It must be possible to have some parts of the page author-controlled, and some parts of the page UA-controlled. For instance, there might be a collaborative editor on the same page as some unrelated inputs.
* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the parts of the page that are collaboratively edited, there is no reason for the UA to make any automatic DOM changes at all.

UndoManager Problem Descriptions

2011-11-07T19:21:32Z

Aryeh Gregor: Create page

Use-cases from [http://rniwa.com/editing/undomanager-usecases.html rniwa's page] and [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-October/033630.html a whatwg thread], patterned after [[Microdata Problem Descriptions]].

General principles:

* Try to make every use-case as easy as possible to deal with. Don't make the common use-cases harder for the sake of allowing rarer use-cases.
* Don't allow any functionality that

== Managing DOM changes ==

'''Scenarios:'''

* A site wants to allow adding a special type of site-specific markup, say .
* A slideshow app. There are multiple slides, each of which contains some editable content. The user is allowed to do rich-text editing on the slides using contenteditable, but also take other actions like adding or removing slides. All changes are either in the DOM, or could be stored in the DOM (using data-* or such).
* A rich text editor provides a source code view that lets users edit HTML directly. In such an app, going to a source code view, edit HTML, and coming back to WYSIWYG view should be treated as one editing operation.
* A code editor that implements auto-completion should be able to use user agent's undo transaction history.

'''Requirements:'''

* It must be possible to associate a set of DOM changes with a custom entry in the undo history. The changes might be to non-editable areas.
* The author must have control over exactly what appears in the undo history. It must be possible to have multiple different DOM changes be one undo history entry, or multiple ones, with customizable labels.
* The author should have to do no special work to undo the action. The UA should track and undo the DOM changes just like for any command.
* Nothing in these use-cases requires that the author be able to specify any special action to be taken on undo/redo. All relevant state is in the DOM, or could be put in the DOM, so the UA can automatically handle undo/redo.

== Separate undo histories ==

'''Scenarios:'''

* A rich text editor has a widget to draw a vector-based illustration. The user should be able to open the widget and modify the illustration while leaving the undo transaction history of the main editor intact.

'''Requirements:'''

* The undo history for the vector image must not be intermixed with the undo history for the rest of the page.

== Non-DOM state ==

'''Scenarios:'''

* A canvas-based drawing app that uses server-side storage. Such an application should provide undo and redo menu items on the user agent's native UI.

'''Requirements:'''

* It must be possible for the author to track non-DOM state (such as canvas operations) in addition to just DOM state.
* It must be possible for the author to run arbitrary JavaScript, such as XHR, on apply/unapply/reapply of a transaction.
* DOM state should still be controlled by the UA. Nothing in the use-case implies that the author wants to make any DOM changes that aren't undone/redone like any other DOM changes. The author must not be forced to deal with manually handling DOM state just because they want to handle non-DOM state.

== Custom control of DOM state ==

'''Scenarios:'''

* Real-time syncing of rich-text edited data with simultaneous multi-user editing. Data pulled in from other users should modify the DOM, but not be included in the undo history. When a user tries to undo something, it needs to undo only that user's changes, using some type of intelligent merge algorithm.
* Collaborative editing of non-rich-text things, such as canvas, as in the previous use-cases.

'''Requirements:'''

* The author must be able to decide exactly how undo/redo are executed if they so choose. They might want to use application-specific heuristics to undo changes when there are conflicts.
* If browsers try to merge changes themselves, the algorithm must be well-defined. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results.
* It must be possible to have some parts of the page author-controlled, and some parts of the page UA-controlled. For instance, there might be a collaborative editor on the same page as some unrelated inputs.
* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the parts of the page that are collaboratively edited, there is no reason for the UA to make any automatic DOM changes at all.

Bugzilla conventions

2011-06-24T17:06:35Z

Aryeh Gregor: /* Priorities */ Typo

These are the conventions used for bugs filed in the W3C Bugzilla for specs also maintained by the WHATWG.

== Subject prefixes ==

Some specific topics have prefixes in the bug summaries to help group the bugs.

;'''<video>'''
:bugs relating to <video>, <audio>, HTMLMediaElement, Controller, WebVTT, WebRTC (PeerConnection and Stream), and closely related topics.
;'''WF2:'''
:bugs relating to form controls.
;'''WF3:'''
:feature requests relating to form controls.
;'''PUB:'''
:something relating to the spec publication process (including anolis, spec splitter, the START and END markers, etc)

== Priorities ==

See [http://lists.w3.org/Archives/Public/public-html/2011Jun/0315.html bug priority policy according to the chairs]. Initial commenters are only allowed to set priority to P3 or lower. Editors and editorial assistants can change it freely. Chairs can decide on a final priority. P1 is very urgent. P2 or P3 is for technical comments except possibly feature requests. P4 or P5 is editorial or non-technical, or feature requests.

== Severities ==

All bugs should be normal severity by default. Typos, grammar mistakes that don't affect normative status, and other such trivial matters can be marked "trivial". Feature requests should be marked "enhancement". Bugs that affect the parser algorithm should be marked "critical". Bugs that are immediately affecting implementors should be marked "blocker". "major" and "minor" are currently unused. The severity field is "owned" by the editor.

== Components ==

The bug filing system should automatically pick the right component. The components are pretty self-explanatory. WHATWG-specific issues should be moved to the "other Hixie drafts" component.

== Resolutions ==

The boilerplate used when resolving the bug comes from: http://lists.w3.org/Archives/Public/public-html/2009Oct/0680.html

The requirements for use of different resolutions are here:

http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#bug-resolutions

== Helpful query links ==

* [http://goo.gl/Zh9tC List of all open and deferred HTML-related bugs]
* [http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=HTML+WG&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=LATER&resolution=REMIND&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= List of LATERed bugs]. Some of these are commonly duped. In particular [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7798 bug 7798] is TextMetrics.height which is often requested.
* [http://www.w3.org/Bugs/Public/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_id_type=anyexact&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&chfieldfrom=&chfieldto=Now&chfieldvalue=&component=HTML%20Canvas%202D%20Context%20%28editor%3A%20Ian%20Hickson%29&component=HTML%20Microdata%20%28editor%3A%20Ian%20Hickson%29&component=HTML5%20spec%20%28editor%3A%20Ian%20Hickson%29&component=other%20Hixie%20drafts%20%28editor%3A%20Ian%20Hickson%29&component=pre-LC1%20HTML%20Canvas%202D%20Context%20%28editor%3A%20Ian%20Hickson%29&component=pre-LC1%20HTML%20Microdata%20%28editor%3A%20Ian%20Hickson%29&component=pre-LC1%20HTML5%20spec%20%28editor%3A%20Ian%20Hickson%29&email1=&email2=&emailtype1=substring&emailtype2=substring&field0-0-0=noop&keywords=&keywords_type=allwords&longdesc=&longdesc_type=allwordssubstr&product=HTML%20WG&query_format=advanced&short_desc=&short_desc_type=allwordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr&type0-0-0=noop&value0-0-0=&votes=&query_based_on=&columnlist=bug_severity%2Cpriority%2Creporter%2Cbug_status%2Cresolution%2Cop_sys%2Cshort_desc%2Cchangeddate List of all open bugs in specs edited by Hixie, sorted by ascending last change time]

Bugzilla conventions

2011-06-23T23:04:49Z

Aryeh Gregor: /* Helpful query links */ Add a helpful link

These are the conventions used for bugs filed in the W3C Bugzilla for specs also maintained by the WHATWG.

== Subject prefixes ==

Some specific topics have prefixes in the bug summaries to help group the bugs.

;'''<video>'''
:bugs relating to <video>, <audio>, HTMLMediaElement, Controller, WebVTT, WebRTC (PeerConnection and Stream), and closely related topics.
;'''WF2:'''
:bugs relating to form controls.
;'''WF3:'''
:feature requests relating to form controls.
;'''PUB:'''
:something relating to the spec publication process (including anolis, spec splitter, the START and END markers, etc)

== Priorities ==

See [http://lists.w3.org/Archives/Public/public-html/2011Jun/0315.html bug priority policy according to the chairs]. Initial commenters are only allowed to set priority to P3 or lower. Editors and editorial assistants can change it freely. Chairs can decide on a final priority. P1 is very urgent. P2 or P3 is for technical comments except possible feature requests. P4 or P5 is editorial or non-technical, or feature requests.

== Severities ==

All bugs should be normal severity by default. Typos, grammar mistakes that don't affect normative status, and other such trivial matters can be marked "trivial". Feature requests should be marked "enhancement". Bugs that affect the parser algorithm should be marked "critical". Bugs that are immediately affecting implementors should be marked "blocker". "major" and "minor" are currently unused. The severity field is "owned" by the editor.

== Components ==

The bug filing system should automatically pick the right component. The components are pretty self-explanatory. WHATWG-specific issues should be moved to the "other Hixie drafts" component.

== Resolutions ==

The boilerplate used when resolving the bug comes from: http://lists.w3.org/Archives/Public/public-html/2009Oct/0680.html

The requirements for use of different resolutions are here:

http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#bug-resolutions

== Helpful query links ==

* [http://goo.gl/Zh9tC List of all open and deferred HTML-related bugs]
* [http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=HTML+WG&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=LATER&resolution=REMIND&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= List of LATERed bugs]. Some of these are commonly duped. In particular [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7798 bug 7798] is TextMetrics.height which is often requested.
* [http://www.w3.org/Bugs/Public/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_id_type=anyexact&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&chfieldfrom=&chfieldto=Now&chfieldvalue=&component=HTML%20Canvas%202D%20Context%20%28editor%3A%20Ian%20Hickson%29&component=HTML%20Microdata%20%28editor%3A%20Ian%20Hickson%29&component=HTML5%20spec%20%28editor%3A%20Ian%20Hickson%29&component=other%20Hixie%20drafts%20%28editor%3A%20Ian%20Hickson%29&component=pre-LC1%20HTML%20Canvas%202D%20Context%20%28editor%3A%20Ian%20Hickson%29&component=pre-LC1%20HTML%20Microdata%20%28editor%3A%20Ian%20Hickson%29&component=pre-LC1%20HTML5%20spec%20%28editor%3A%20Ian%20Hickson%29&email1=&email2=&emailtype1=substring&emailtype2=substring&field0-0-0=noop&keywords=&keywords_type=allwords&longdesc=&longdesc_type=allwordssubstr&product=HTML%20WG&query_format=advanced&short_desc=&short_desc_type=allwordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr&type0-0-0=noop&value0-0-0=&votes=&query_based_on=&columnlist=bug_severity%2Cpriority%2Creporter%2Cbug_status%2Cresolution%2Cop_sys%2Cshort_desc%2Cchangeddate List of all open bugs in specs edited by Hixie, sorted by ascending last change time]

Bugzilla conventions

2011-06-23T16:36:34Z

Aryeh Gregor: /* Priorities and Severities */ Update

Forking

2011-05-04T20:15:56Z

Aryeh Gregor: /* Existing forks of HTML */ Describe some of the forks a bit.

The purpose of this page is to summarize information and arguments relevant to whether it makes sense for web specification copyright licenses to permit [[Wikipedia:Fork (software development)|forking]].

For our purposes, there are two different approaches to forking.

: Language Forking
:: An alternative development path for the language created without using existing specification text as the basis of the work.
: Specification Forking
:: An alternative development path using existing specification text as the basis of a derivative work.

Since a ''language fork'' is not a derivative work according to copyright law, it may be done without the permission of the copyright holder. A ''specification fork'', however, requires a permissive licence or explicit permission from the copyright holder.

Standard licenses that permit specification forking include [https://creativecommons.org/publicdomain/zero/1.0/ CC0], the [http://opensource.org/licenses/mit-license.php MIT license], and the [http://www.opensource.org/licenses/bsd-license.php BSD licenses].

This page focuses on whether the W3C's HTML5 specification should allow forks, as the WHATWG version always has.

== Existing forks of HTML ==
(based on [http://krijnhoetmer.nl/irc-logs/whatwg/20110430#l-179 IRC comment] by Maciej; possibly not everything here is strictly a fork, could use classification and explanation work)

=== W3C-hosted forks ===

* [http://www.w3.org/TR/xhtml-basic/ XHTML Basic]
* [http://www.w3.org/TR/1999/NOTE-html40-mobile-19990315/ HTML 4 Mobile]
* [http://www.w3.org/TR/xhtml2/ XHTML 2]
* [http://www.w3.org/TR/xhtml-print/ XHTML-Print]
* [http://dev.w3.org/html5/spec-author-view/ HTML5 Edition for Web Authors]
* [http://dev.w3.org/html5/markup/ HTML: The Markup Language]

=== W3C-published but disavowed forks ===

* [http://www.w3.org/TR/NOTE-Submission-HDML-spec.html HDML]
* [http://www.w3.org/TR/2002/NOTE-XHTMLplusSMIL-20020131/ XHTML+SMIL]
* [http://www.w3.org/TR/1998/NOTE-compactHTML-19980209/ CHTML]

=== Other forks ===

* [http://www.scss.tcd.ie/misc/15445/15445.html ISO HTML]: Diff spec.
* [http://www.openmobilealliance.org/tech/affiliates/wap/wap-277-xhtmlmp-20011029-a.pdf XHTML-MP]: Apparently no free download. Reportedly not widely used.
* [http://www.wapforum.org/what/technical.htm WML]: Apparently no free download. Reportedly very widely used and extremely harmful.
* [http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=19886 WTVML]: Apparently no free download.
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/ WHATWG HTML]: No comment.
* [http://www.ce.org/Standards/browseByCommittee_2757.asp CE-HTML]: Apparently only a preview is available for free, which contains almost nothing beyond the table of contents.
* [http://idpf.org/epub/30/spec/epub30-publications.html EPUB]: Diff spec.
* [http://html4all.org/HTMLDraft.html HTML 4.1]: Accessibility-oriented fork. Seems to attempt to respec from scratch, but it doesn't sound like it has anyone actually implementing it.

=== Not really forks ===
* [http://developers.whatwg.org HTML5 for Web developers]: A subset of WHATWG HTML.
* [http://w3c-test.org/html/tests/submission/PhilipTaylor/annotated-spec/canvas.html Philip Taylor's annotated canvas spec]: No normative differences, or at least isn't supposed to have normative differences.

== Organizational forks ==
One argument presented in favor of allowing forks is that if the W3C ever makes poor decisions that compromise the quality of its standards, other organizations should have the right to issue competing standards, with implementers agreeing to follow the better standard. When the W3C owns the right to large, established specifications that it doesn't permit others to fork, this becomes harder. Looking at cases where standards authors have abandoned an existing standards group to form their own should give an idea of whether this tends to be a good or bad thing.

=== W3C competing with IETF ===
The W3C itself was founded at least partly because Tim Berners-Lee felt that standardization at the IETF wasn't working well. As he writes in his book, [http://www.w3.org/People/Berners-Lee/Weaving/Overview.html ''Weaving the Web''] (pp. 62-3):

<blockquote>Progress in the [IETF's] URI working group was slow, partly due to the number of endless philosophical rat holes down which technical conversations would disappear. . . . Sometimes there was a core philosophy being argued, and from my point of view that was not up for compromise. Sometimes there was a basically arbitrary decision (like which punctuation characters to use) that I had already made, and changing it would only mean that millions of Web browsers and existing links would have to be changed.</blockquote>

In practice, the W3C has wound up cooperating with the IETF more than competing.

=== WHATWG competing with W3C ===
After HTML 4.01 was finalized in 1998, no new features were added to the HTML markup language other than in XHTML variants that browsers didn't implement. Thus HTML as a standard markup language did not progress at all between about 1998 and 2004. In 2004, Mozilla and Opera requested permission from the W3C to work on improving non-XML-based versions of HTML, and they were denied permission. Apple, Mozilla, and Opera then founded the WHATWG, which began work on a new version of the HTML specification outside the W3C. In a couple of years, the WHATWG rewrote the HTML standard from scratch, made it drastically more precise, and added many new highly-demanded features (such as video and canvas) that were previously only available through proprietary plugins. In 2007, the W3C formed an HTML Working Group again to work on non-XML-based versions of HTML, based on and in conjunction with the work of the WHATWG.

== Modularization ==

[http://www.w3.org/TR/xhtml-modularization/ XHTML Modularization] has the goal of "providing a means for subsetting and extending XHTML, a feature needed for extending XHTML's reach onto emerging platforms". Although this is not technically a fork (in the sense that it does not imply taking the W3C spec text and rewriting portions of it), the ability to create new HTML-derived specs that add or replace functionality carries many of the same risks that are brought up in the context of forking.

== Supposed risks of forking ==

* "A national government could create its own intentionally incompatible national version of the html specification in order to prevent general Web access from within that country": This argument is wrong at multiple levels:
** A national government could exempt itself from copyright anyway. Even [http://arstechnica.com/tech-policy/news/2008/08/air-force-cracks-software-carpet-bombs-dmca.ars the US government] does not consider itself bound by copyright law in all cases.
** A specification is only needed if there is a desire for multiple independent interoperable implementations, i.e., if competition is being encouraged. But what government would on the one hand encourage competition amongst browser vendors and on the other hand prevent those browser vendors from implementing other versions of HTML?
** In practice, it would be economically impractical to control the Web by developing a parallel HTML that is similar enough that the W3C spec could be used as a basis, but different enough that it is incompatible with the Web's HTML. In reality, countries use content filtering software to do such control (q.v., China).

* "Other undesirable forks could be for device specific variants of specs where it would be better for those groups to come into W3C [...] than to splinter html": When the W3C forks HTML (as it has in the past, see the list above), it is just as bad as when anyone else does. There is nothing special about the W3C here.
** In practice, vendors who want to add device-specific features commonly just add new features without forking the spec. For instance, Apple has made up its own [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/configuringwebapplications/configuringwebapplications.html proprietary features] such as <meta name="apple-touch-icon"> and <meta name="apple-mobile-web-app-capable"> to allow web pages to integrate better with the iOS browser. Forking the whole HTML spec would be a waste of time.

== Advantages of allowing forking ==

* It encourages the W3C to do a good job, because of the risk that if the W3C does ''not'' do a good job, it will lose relevance. This has already been shown to be beneficial both to the W3C and the Web at large with HTML5 itself: the W3C tried to strongarm the Web into abandoning HTML, and when the WHATWG worked on it instead, the W3C changed its mind. This demonstrates the benefit of allowing forking (though in this case, it turns out copyright restrictions were not any kind of barrier to forking, because HTML4 wasn't good enough to be a useful starting point and we instead started from scratch).

== Reasons preventing forking is not necessary ==

* If the W3C is the best place to work on specs, then people will not need to fork, they'll just work on them at the W3C.

Forking

2011-05-02T14:17:46Z

Aryeh Gregor: /* Supposed risks of forking */ Mention Apple making up proprietary features to support iOS instead of forking the spec

The purpose of this page is to summarize information and arguments relevant to whether it makes sense for web specification copyright licenses to permit [[Wikipedia:Fork (software development)|forking]].

For our purposes, there are two different approaches to forking.

: Language Forking
:: An alternative development path for the language created without using existing specification text as the basis of the work.
: Specification Forking
:: An alternative development path using existing specification text as the basis of a derivative work.

Since a ''language fork'' is not a derivative work according to copyright law, it may be done without the permission of the copyright holder. A ''specification fork'', however, requires a permissive licence or explicit permission from the copyright holder.

Standard licenses that permit specification forking include [https://creativecommons.org/publicdomain/zero/1.0/ CC0], the [http://opensource.org/licenses/mit-license.php MIT license], and the [http://www.opensource.org/licenses/bsd-license.php BSD licenses].

This page focuses on whether the W3C's HTML5 specification should allow forks, as the WHATWG version always has.

== Existing forks of HTML ==
(based on [http://krijnhoetmer.nl/irc-logs/whatwg/20110430#l-179 IRC comment] by Maciej; possibly not everything here is strictly a fork, could use classification and explanation work)

=== W3C-hosted forks ===

* [http://www.w3.org/TR/xhtml-basic/ XHTML Basic]
* [http://www.w3.org/TR/1999/NOTE-html40-mobile-19990315/ HTML 4 Mobile]
* [http://www.w3.org/TR/xhtml2/ XHTML 2]
* [http://www.w3.org/TR/xhtml-print/ XHTML-Print]

=== W3C-published but disavowed forks ===

* [http://www.w3.org/TR/NOTE-Submission-HDML-spec.html HDML]
* [http://www.w3.org/TR/2002/NOTE-XHTMLplusSMIL-20020131/ XHTML+SMIL]
* [http://www.w3.org/TR/1998/NOTE-compactHTML-19980209/ CHTML]

=== Other forks ===

* [http://jp29.org/iso.htm ISO HTML]
* [http://www.openmobilealliance.org/tech/affiliates/wap/wap-277-xhtmlmp-20011029-a.pdf XHTML-MP]
* [http://www.wapforum.org/what/technical.htm WML] (apparently no free download)
* [http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=19886 WTVML] (apparently no free download)
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/ WHATWG HTML]
* [http://www.ce.org/Standards/browseByCommittee_2757.asp CE-HTML] (apparently only a preview available for free)
* [http://idpf.org/epub/30/spec/epub30-publications.html EPUB]
* [http://html4all.org/HTMLDraft.html HTML 4.1]

== Organizational forks ==
One argument presented in favor of allowing forks is that if the W3C ever makes poor decisions that compromise the quality of its standards, other organizations should have the right to issue competing standards, with implementers agreeing to follow the better standard. When the W3C owns the right to large, established specifications that it doesn't permit others to fork, this becomes harder. Looking at cases where standards authors have abandoned an existing standards group to form their own should give an idea of whether this tends to be a good or bad thing.

=== W3C competing with IETF ===
The W3C itself was founded at least partly because Tim Berners-Lee felt that standardization at the IETF wasn't working well. As he writes in his book, [http://www.w3.org/People/Berners-Lee/Weaving/Overview.html ''Weaving the Web''] (pp. 62-3):

<blockquote>Progress in the [IETF's] URI working group was slow, partly due to the number of endless philosophical rat holes down which technical conversations would disappear. . . . Sometimes there was a core philosophy being argued, and from my point of view that was not up for compromise. Sometimes there was a basically arbitrary decision (like which punctuation characters to use) that I had already made, and changing it would only mean that millions of Web browsers and existing links would have to be changed.</blockquote>

In practice, the W3C has wound up cooperating with the IETF more than competing.

=== WHATWG competing with W3C ===
After HTML 4.01 was finalized in 1998, no new features were added to the HTML markup language other than in XHTML variants that browsers didn't implement. Thus HTML as a standard markup language did not progress at all between about 1998 and 2004. In 2004, Mozilla and Opera requested permission from the W3C to work on improving non-XML-based versions of HTML, and they were denied permission. Apple, Mozilla, and Opera then founded the WHATWG, which began work on a new version of the HTML specification outside the W3C. In a couple of years, the WHATWG rewrote the HTML standard from scratch, made it drastically more precise, and added many new highly-demanded features (such as video and canvas) that were previously only available through proprietary plugins. In 2007, the W3C formed an HTML Working Group again to work on non-XML-based versions of HTML, based on and in conjunction with the work of the WHATWG.

== Modularization ==

[http://www.w3.org/TR/xhtml-modularization/ XHTML Modularization] has the goal of "providing a means for subsetting and extending XHTML, a feature needed for extending XHTML's reach onto emerging platforms". Although this is not technically a fork (in the sense that it does not imply taking the W3C spec text and rewriting portions of it), the ability to create new HTML-derived specs that add or replace functionality carries many of the same risks that are brought up in the context of forking.

== Supposed risks of forking ==

* "A national government could create its own intentionally incompatible national version of the html specification in order to prevent general Web access from within that country": This argument is wrong at multiple levels:
** A national government could exempt itself from copyright anyway. Even [http://arstechnica.com/tech-policy/news/2008/08/air-force-cracks-software-carpet-bombs-dmca.ars the US government] does not consider itself bound by copyright law in all cases.
** A specification is only needed if there is a desire for multiple independent interoperable implementations, i.e., if competition is being encouraged. But what government would on the one hand encourage competition amongst browser vendors and on the other hand prevent those browser vendors from implementing other versions of HTML?
** In practice, it would be economically impractical to control the Web by developing a parallel HTML that is similar enough that the W3C spec could be used as a basis, but different enough that it is incompatible with the Web's HTML. In reality, countries use content filtering software to do such control (e.g., China).

* "Other undesirable forks could be for device specific variants of specs where it would be better for those groups to come into W3C [...] than to splinter html": When the W3C forks HTML (as it has in the past, see the list above), it is just as bad as when anyone else does. There is nothing special about the W3C here.
** In practice, vendors who want to add device-specific features commonly just add new features without forking the spec. For instance, Apple has made up its own [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/configuringwebapplications/configuringwebapplications.html proprietary features] such as <meta name="apple-touch-icon"> and <meta name="apple-mobile-web-app-capable"> to allow web pages to integrate better with the iOS browser. Forking the whole HTML spec would be a waste of time.

== Advantages of allowing forking ==

* It encourages the W3C to do a good job, because of the risk that if the W3C does ''not'' do a good job, it will lose relevance. This has already been shown to be beneficial both to the W3C and the Web at large with HTML5 itself: the W3C tried to strongarm the Web into abandoning HTML, and when the WHATWG worked on it instead, the W3C changed its mind. This demonstrates the benefit of allowing forking (though in this case, it turns out copyright restrictions were not any kind of barrier to forking, because HTML4 wasn't good enough to be a useful starting point and we instead started from scratch).

== Reasons preventing forking is not necessary ==

* If the W3C is the best place to work on specs, then people will not need to fork, they'll just work on them at the W3C.

Forking

2011-05-02T14:14:09Z

Aryeh Gregor: /* Supposed risks of forking */ Remove something that's not an argument against the risks of forking, it's an argument about the irrelevance of W3C licensing to the *possibility* of forking.

The purpose of this page is to summarize information and arguments relevant to whether it makes sense for web specification copyright licenses to permit [[Wikipedia:Fork (software development)|forking]].

For our purposes, there are two different approaches to forking.

: Language Forking
:: An alternative development path for the language created without using existing specification text as the basis of the work.
: Specification Forking
:: An alternative development path using existing specification text as the basis of a derivative work.

Since a ''language fork'' is not a derivative work according to copyright law, it may be done without the permission of the copyright holder. A ''specification fork'', however, requires a permissive licence or explicit permission from the copyright holder.

Standard licenses that permit specification forking include [https://creativecommons.org/publicdomain/zero/1.0/ CC0], the [http://opensource.org/licenses/mit-license.php MIT license], and the [http://www.opensource.org/licenses/bsd-license.php BSD licenses].

This page focuses on whether the W3C's HTML5 specification should allow forks, as the WHATWG version always has.

== Existing forks of HTML ==
(based on [http://krijnhoetmer.nl/irc-logs/whatwg/20110430#l-179 IRC comment] by Maciej; possibly not everything here is strictly a fork, could use classification and explanation work)

=== W3C-hosted forks ===

* [http://www.w3.org/TR/xhtml-basic/ XHTML Basic]
* [http://www.w3.org/TR/1999/NOTE-html40-mobile-19990315/ HTML 4 Mobile]
* [http://www.w3.org/TR/xhtml2/ XHTML 2]
* [http://www.w3.org/TR/xhtml-print/ XHTML-Print]

=== W3C-published but disavowed forks ===

* [http://www.w3.org/TR/NOTE-Submission-HDML-spec.html HDML]
* [http://www.w3.org/TR/2002/NOTE-XHTMLplusSMIL-20020131/ XHTML+SMIL]
* [http://www.w3.org/TR/1998/NOTE-compactHTML-19980209/ CHTML]

=== Other forks ===

* [http://jp29.org/iso.htm ISO HTML]
* [http://www.openmobilealliance.org/tech/affiliates/wap/wap-277-xhtmlmp-20011029-a.pdf XHTML-MP]
* [http://www.wapforum.org/what/technical.htm WML] (apparently no free download)
* [http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=19886 WTVML] (apparently no free download)
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/ WHATWG HTML]
* [http://www.ce.org/Standards/browseByCommittee_2757.asp CE-HTML] (apparently only a preview available for free)
* [http://idpf.org/epub/30/spec/epub30-publications.html EPUB]
* [http://html4all.org/HTMLDraft.html HTML 4.1]

== Organizational forks ==
One argument presented in favor of allowing forks is that if the W3C ever makes poor decisions that compromise the quality of its standards, other organizations should have the right to issue competing standards, with implementers agreeing to follow the better standard. When the W3C owns the right to large, established specifications that it doesn't permit others to fork, this becomes harder. Looking at cases where standards authors have abandoned an existing standards group to form their own should give an idea of whether this tends to be a good or bad thing.

=== W3C competing with IETF ===
The W3C itself was founded at least partly because Tim Berners-Lee felt that standardization at the IETF wasn't working well. As he writes in his book, [http://www.w3.org/People/Berners-Lee/Weaving/Overview.html ''Weaving the Web''] (pp. 62-3):

<blockquote>Progress in the [IETF's] URI working group was slow, partly due to the number of endless philosophical rat holes down which technical conversations would disappear. . . . Sometimes there was a core philosophy being argued, and from my point of view that was not up for compromise. Sometimes there was a basically arbitrary decision (like which punctuation characters to use) that I had already made, and changing it would only mean that millions of Web browsers and existing links would have to be changed.</blockquote>

In practice, the W3C has wound up cooperating with the IETF more than competing.

=== WHATWG competing with W3C ===
After HTML 4.01 was finalized in 1998, no new features were added to the HTML markup language other than in XHTML variants that browsers didn't implement. Thus HTML as a standard markup language did not progress at all between about 1998 and 2004. In 2004, Mozilla and Opera requested permission from the W3C to work on improving non-XML-based versions of HTML, and they were denied permission. Apple, Mozilla, and Opera then founded the WHATWG, which began work on a new version of the HTML specification outside the W3C. In a couple of years, the WHATWG rewrote the HTML standard from scratch, made it drastically more precise, and added many new highly-demanded features (such as video and canvas) that were previously only available through proprietary plugins. In 2007, the W3C formed an HTML Working Group again to work on non-XML-based versions of HTML, based on and in conjunction with the work of the WHATWG.

== Modularization ==

[http://www.w3.org/TR/xhtml-modularization/ XHTML Modularization] has the goal of "providing a means for subsetting and extending XHTML, a feature needed for extending XHTML's reach onto emerging platforms". Although this is not technically a fork (in the sense that it does not imply taking the W3C spec text and rewriting portions of it), the ability to create new HTML-derived specs that add or replace functionality carries many of the same risks that are brought up in the context of forking.

== Supposed risks of forking ==

* "A national government could create its own intentionally incompatible national version of the html specification in order to prevent general Web access from within that country": This argument is wrong at multiple levels:
** A national government could exempt itself from copyright anyway. Even [http://arstechnica.com/tech-policy/news/2008/08/air-force-cracks-software-carpet-bombs-dmca.ars the US government] does not consider itself bound by copyright law in all cases.
** A specification is only needed if there is a desire for multiple independent interoperable implementations, i.e., if competition is being encouraged. But what government would on the one hand encourage competition amongst browser vendors and on the other hand prevent those browser vendors from implementing other versions of HTML?
** In practice, it would be economically impractical to control the Web by developing a parallel HTML that is similar enough that the W3C spec could be used as a basis, but different enough that it is incompatible with the Web's HTML. In reality, countries use content filtering software to do such control (c.f. China).

* "Other undesirable forks could be for device specific variants of specs where it would be better for those groups to come into W3C [...] than to splinter html": When the W3C forks HTML (as it has in the past, see the list above), it is just as bad as when anyone else does. There is nothing special about the W3C here.

== Advantages of allowing forking ==

* It encourages the W3C to do a good job, because of the risk that if the W3C does ''not'' do a good job, it will lose relevance. This has already been shown to be beneficial both to the W3C and the Web at large with HTML5 itself: the W3C tried to strongarm the Web into abandoning HTML, and when the WHATWG worked on it instead, the W3C changed its mind. This demonstrates the benefit of allowing forking (though in this case, it turns out copyright restrictions were not any kind of barrier to forking, because HTML4 wasn't good enough to be a useful starting point and we instead started from scratch).

== Reasons preventing forking is not necessary ==

* If the W3C is the best place to work on specs, then people will not need to fork, they'll just work on them at the W3C.

Forking

2011-05-02T14:12:41Z

Aryeh Gregor: /* Supposed risks of forking */ Clarify copyright law's effect on governments

The purpose of this page is to summarize information and arguments relevant to whether it makes sense for web specification copyright licenses to permit [[Wikipedia:Fork (software development)|forking]].

For our purposes, there are two different approaches to forking.

: Language Forking
:: An alternative development path for the language created without using existing specification text as the basis of the work.
: Specification Forking
:: An alternative development path using existing specification text as the basis of a derivative work.

Since a ''language fork'' is not a derivative work according to copyright law, it may be done without the permission of the copyright holder. A ''specification fork'', however, requires a permissive licence or explicit permission from the copyright holder.

Standard licenses that permit specification forking include [https://creativecommons.org/publicdomain/zero/1.0/ CC0], the [http://opensource.org/licenses/mit-license.php MIT license], and the [http://www.opensource.org/licenses/bsd-license.php BSD licenses].

This page focuses on whether the W3C's HTML5 specification should allow forks, as the WHATWG version always has.

== Existing forks of HTML ==
(based on [http://krijnhoetmer.nl/irc-logs/whatwg/20110430#l-179 IRC comment] by Maciej; possibly not everything here is strictly a fork, could use classification and explanation work)

=== W3C-hosted forks ===

* [http://www.w3.org/TR/xhtml-basic/ XHTML Basic]
* [http://www.w3.org/TR/1999/NOTE-html40-mobile-19990315/ HTML 4 Mobile]
* [http://www.w3.org/TR/xhtml2/ XHTML 2]
* [http://www.w3.org/TR/xhtml-print/ XHTML-Print]

=== W3C-published but disavowed forks ===

* [http://www.w3.org/TR/NOTE-Submission-HDML-spec.html HDML]
* [http://www.w3.org/TR/2002/NOTE-XHTMLplusSMIL-20020131/ XHTML+SMIL]
* [http://www.w3.org/TR/1998/NOTE-compactHTML-19980209/ CHTML]

=== Other forks ===

* [http://jp29.org/iso.htm ISO HTML]
* [http://www.openmobilealliance.org/tech/affiliates/wap/wap-277-xhtmlmp-20011029-a.pdf XHTML-MP]
* [http://www.wapforum.org/what/technical.htm WML] (apparently no free download)
* [http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=19886 WTVML] (apparently no free download)
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/ WHATWG HTML]
* [http://www.ce.org/Standards/browseByCommittee_2757.asp CE-HTML] (apparently only a preview available for free)
* [http://idpf.org/epub/30/spec/epub30-publications.html EPUB]
* [http://html4all.org/HTMLDraft.html HTML 4.1]

== Organizational forks ==
One argument presented in favor of allowing forks is that if the W3C ever makes poor decisions that compromise the quality of its standards, other organizations should have the right to issue competing standards, with implementers agreeing to follow the better standard. When the W3C owns the right to large, established specifications that it doesn't permit others to fork, this becomes harder. Looking at cases where standards authors have abandoned an existing standards group to form their own should give an idea of whether this tends to be a good or bad thing.

=== W3C competing with IETF ===
The W3C itself was founded at least partly because Tim Berners-Lee felt that standardization at the IETF wasn't working well. As he writes in his book, [http://www.w3.org/People/Berners-Lee/Weaving/Overview.html ''Weaving the Web''] (pp. 62-3):

<blockquote>Progress in the [IETF's] URI working group was slow, partly due to the number of endless philosophical rat holes down which technical conversations would disappear. . . . Sometimes there was a core philosophy being argued, and from my point of view that was not up for compromise. Sometimes there was a basically arbitrary decision (like which punctuation characters to use) that I had already made, and changing it would only mean that millions of Web browsers and existing links would have to be changed.</blockquote>

In practice, the W3C has wound up cooperating with the IETF more than competing.

=== WHATWG competing with W3C ===
After HTML 4.01 was finalized in 1998, no new features were added to the HTML markup language other than in XHTML variants that browsers didn't implement. Thus HTML as a standard markup language did not progress at all between about 1998 and 2004. In 2004, Mozilla and Opera requested permission from the W3C to work on improving non-XML-based versions of HTML, and they were denied permission. Apple, Mozilla, and Opera then founded the WHATWG, which began work on a new version of the HTML specification outside the W3C. In a couple of years, the WHATWG rewrote the HTML standard from scratch, made it drastically more precise, and added many new highly-demanded features (such as video and canvas) that were previously only available through proprietary plugins. In 2007, the W3C formed an HTML Working Group again to work on non-XML-based versions of HTML, based on and in conjunction with the work of the WHATWG.

== Modularization ==

[http://www.w3.org/TR/xhtml-modularization/ XHTML Modularization] has the goal of "providing a means for subsetting and extending XHTML, a feature needed for extending XHTML's reach onto emerging platforms". Although this is not technically a fork (in the sense that it does not imply taking the W3C spec text and rewriting portions of it), the ability to create new HTML-derived specs that add or replace functionality carries many of the same risks that are brought up in the context of forking.

== Supposed risks of forking ==

* "A national government could create its own intentionally incompatible national version of the html specification in order to prevent general Web access from within that country": This argument is wrong at multiple levels:
** A national government could exempt itself from copyright anyway. Even [http://arstechnica.com/tech-policy/news/2008/08/air-force-cracks-software-carpet-bombs-dmca.ars the US government] does not consider itself bound by copyright law in all cases.
** A specification is only needed if there is a desire for multiple independent interoperable implementations, i.e., if competition is being encouraged. But what government would on the one hand encourage competition amongst browser vendors and on the other hand prevent those browser vendors from implementing other versions of HTML?
** In practice, it would be economically impractical to control the Web by developing a parallel HTML that is similar enough that the W3C spec could be used as a basis, but different enough that it is incompatible with the Web's HTML. In reality, countries use content filtering software to do such control (c.f. China).
** Whether the W3C allows forking or not, and even if we grant that a license could stop this, this scenario could already happen because the entire HTML spec is already under a liberal license at the WHATWG.

* "Other undesirable forks could be for device specific variants of specs where it would be better for those groups to come into W3C [...] than to splinter html": When the W3C forks HTML (as it has in the past, see the list above), it is just as bad as when anyone else does. There is nothing special about the W3C here.

== Advantages of allowing forking ==

* It encourages the W3C to do a good job, because of the risk that if the W3C does ''not'' do a good job, it will lose relevance. This has already been shown to be beneficial both to the W3C and the Web at large with HTML5 itself: the W3C tried to strongarm the Web into abandoning HTML, and when the WHATWG worked on it instead, the W3C changed its mind. This demonstrates the benefit of allowing forking (though in this case, it turns out copyright restrictions were not any kind of barrier to forking, because HTML4 wasn't good enough to be a useful starting point and we instead started from scratch).

== Reasons preventing forking is not necessary ==

* If the W3C is the best place to work on specs, then people will not need to fork, they'll just work on them at the W3C.

Forking

2011-05-01T18:33:34Z

Aryeh Gregor: Start a page

The purpose of this page is to summarize information and arguments relevant to whether it makes sense for web specification copyright licenses to permit [[Wikipedia:Fork (software development)|forking]]. For our purposes, forking means the ability for a third party to redistribute modified versions of the specification without the permission of the copyright holders. Standard licenses that permit forking include [http://creativecommons.org/choose/zero/ CC0], the [http://opensource.org/licenses/mit-license.php MIT license], and the [http://www.opensource.org/licenses/bsd-license.php BSD licenses].

More specifically, this page focuses on whether the W3C's HTML5 specification should allow forks, as the WHATWG version always has.

== Existing forks of HTML ==
(based on [http://krijnhoetmer.nl/irc-logs/whatwg/20110430#l-179 IRC comment] by Maciej; possibly not everything here is strictly a fork, could use classification and explanation work)

=== W3C-hosted forks ===

* [http://www.w3.org/TR/1998/NOTE-compactHTML-19980209/ CHTML]
* [http://www.w3.org/TR/xhtml-basic/ XHTML Basic]
* [http://www.w3.org/TR/xhtml2/ XHTML 2]
* [http://www.w3.org/TR/xhtml-print/ XHTML-Print]
* [http://www.w3.org/TR/NOTE-Submission-HDML-spec.html HDML]

=== Other forks ===

* [http://jp29.org/iso.htm ISO HTML]
* [http://www.openmobilealliance.org/tech/affiliates/wap/wap-277-xhtmlmp-20011029-a.pdf XHTML-MP]
* [http://www.wapforum.org/what/technical.htm WML] (apparently no free download)
* [http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=19886 WTVML] (apparently no free download)
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/ WHATWG HTML]
* [http://www.ce.org/Standards/browseByCommittee_2757.asp CE-HTML] (apparently only a preview available for free)
* [http://idpf.org/epub/30/spec/epub30-publications.html EPUB]

== Organizational forks ==
One argument presented in favor of allowing forks is that if the W3C ever makes poor decisions that compromise the quality of its standards, other organizations should have the right to issue competing standards, with implementers agreeing to follow the better standard. When the W3C owns the right to large, established specifications that it doesn't permit others to fork, this becomes harder. Looking at cases where standards authors have abandoned an existing standards group to form their own should give an idea of whether this tends to be a good or bad thing.

=== W3C competing with IETF ===
The W3C itself was founded at least partly because Tim Berners-Lee felt that standardization at the IETF wasn't working well. As he writes in his book, [http://www.w3.org/People/Berners-Lee/Weaving/Overview.html ''Weaving the Web''] (pp. 62-3):

<blockquote>Progress in the [IETF's] URI working group was slow, partly due to the number of endless philosophical rat holes down which technical conversations would disappear. . . . Sometimes there was a core philosophy being argued, and from my point of view that was not up for compromise. Sometimes there was a basically arbitrary decision (like which punctuation characters to use) that I had already made, and changing it would only mean that millions of Web browsers and existing links would have to be changed.</blockquote>

In practice, the W3C has wound up cooperating with the IETF more than competing.

=== WHATWG competing with W3C ===
After HTML 4.01 was finalized in 1998, no new features were added to the HTML markup language other than in XHTML variants that browsers didn't implement. Thus HTML as a standard markup language did not progress at all between about 1998 and 2004. In 2004, Mozilla and Opera requested permission from the W3C to work on improving non-XML-based versions of HTML, and they were denied permission. Apple, Mozilla, and Opera then founded the WHATWG, which began work on a new version of the HTML specification outside the W3C. In a couple of years, the WHATWG rewrote the HTML standard from scratch, made it drastically more precise, and added many new highly-demanded features (such as video and canvas) that were previously only available through proprietary plugins. In 2007, the W3C formed an HTML Working Group again to work on non-XML-based versions of HTML, based on and in conjunction with the work of the WHATWG.

User:Aryeh Gregor

2010-05-06T01:23:09Z

Aryeh Gregor: Revert test

A.k.a. [[mw:User:Simetrical|Simetrical]].

User:Aryeh Gregor

2010-05-06T01:22:59Z

Aryeh Gregor: Test

A.k.a. [[mw:User:Simetrical|Simetrical]].

http://whatwg.org

User:Aryeh Gregor

2010-05-06T01:17:48Z

Aryeh Gregor: Created page with 'A.k.a. Simetrical.'

A.k.a. [[mw:User:Simetrical|Simetrical]].