This week the HTML specification gained four new methods and also lost some weight due to higher quality “competing” proposals for editing related APIs.
registerProtocolHandler() and registerContentHandler() gained four complementary methods. isProtocolHandlerRegistered() and isContentHandlerRegistered() to determine whether the user is already using the site in question to handle the specified scheme or media type, and unregisterProtocolHandler() and unregisterContentHandler() to give the site the ability to offer an opt-out user interface.
Editing Exodus
The UndoManager proposal contained in the HTML specification has now been removed in favor of the work Ryosuke Niwa has been doing on UndoManager and DOM Transaction.
The execCommand() method and friends have also been removed from the HTML specification in favor of the work Aryeh Gregor has been doing on HTML Editing APIs.
Editing Meeting
A couple of people from Google and Mozilla came together in Canada to discuss the various challenges authors face with editing on the web and how they can be tackled. Ehsan Akhgari wrote a detailed report Future of editing on the web that is well worth reading.
Posted in Weekly Review | Comments Off on WHATWG Weekly: Rich-Text Editing on the Web
WHATWG Weekly is somewhat irregularly updated as its writer has a somewhat chaotic vacation schedule. The specification meanwhile keeps getting refined, with the latest significant change being a security update to registerProtocolHandler() and registerContentHandler(). These methods provide better platform integration, by letting web pages become responsible for handling e.g. mailto or irc URLs. This security update introduces a whitelist for registerProtocolHandler() along with the ability for everyone to mint their own whitelisted URL schemes that are required to start with web+. registerContentHandler() meanwhile gets a blacklist for the time being as a suitable way to define a whitelist has not been found.
UndoManager and DOM Transaction
Ryosuke Niwa has been working on an API proposal to manage the undo transaction history. This proposal is deemed better than what is currently in the HTML specification and is being sorted out on the WHATWG list. Once this is completed web applications will finally get proper undo/redo behavior.
HTML/XML Task Force
A while ago the W3C TAG set up a Task Force to investigate how HTML and XML can be more closely aligned. A preliminary report is available: HTML/XML Task Force Report.
W3C Community Groups
The W3C set up Community Groups the other day making it easier for people to develop standards at the W3C without all the overhead that previously entailed. Aryeh Gregor already set up the HTML Editing APIs Community Group to work on HTML Editing APIs. Feel free to join the group or start your own!
Component Model Update
Dimitri “good morning” Glazkov posted an update on working out the component model for the web (formerly XBL). To learn more check out the component model page on the WHATWG wiki which contains a good overview of the technology.
Posted in Weekly Review | Comments Off on WHATWG Weekly: UndoManager, HTML/XML, Component Model
WHATWG Weekly has been on a little summer break. Since we were gone over hundred changes were made to the HTML specification, the W3C HTML5 Last Call period is over, and Maciej solicited input on HTML.next.
The changes made to the HTML specifications have been in response to Last Call comments, making clarifications, fixing typos, and a couple of relatively major changes, such as having interfaces inherit (e.g. Window) from the EventTarget interface rather than implement it. Take a look at the HTML5 Tracker for more detail.
Posted in Weekly Review | Comments Off on WHATWG Weekly: Brief Mid-August Update
(This is a cross-post from the mailing list, reformatted as HTML.)
Since February, I've been working on writing a detailed specification for browser editing, primarily the document.execCommand() and document.queryCommand*() methods. These were created by Microsoft in the 1990s and were subsequently adopted in some form by all other browsers, and today browsers have to implement them to be compatible with web content, but no detailed specification ever existed. Interoperability is practically nonexistent as a result, which has
driven all major content editing frameworks away from using execCommand(). (For instance, I began typing this in WordPress' WYSIWYG editor, which uses TinyMCE – a major editor that avoids execCommand() entirely.) Hopefully we can start to fix that and make these APIs a part of the web platform that just works.
The current version of the specification is about fifty pages printed, and supersedes the Editing APIs section of HTML (which is more like two pages). In the style of modern web specs, it
is phrased in terms of algorithms that attempt to cover all corner cases unambiguously and leave no behavior undefined, and it tries to match the behavior of existing browsers to the greatest extent possible. At this point, it's stable and complete enough that I believe it's ready for serious review by implementers, and I would like as much detailed feedback as possible.
There is a basically complete JavaScript implementation, which is used to produce expected results for a largely undocumented and entirely ad hoc test suite. I used the tests as an aid to writing the spec, and they probably aren't well suited to aid implementers in implementing it. I will probably get around to porting them to something like testharness.js at some point. I haven't tried testing my implementation on real-world sites, only on artificial input, so I don't know at this point how implementable it really is, but the JS implementation means that it at least has large parts that make sense.
Anyone reviewing the spec should be advised that I put extensive rationale in HTML comments. If you want to know why the spec says what it does, check the HTML source. I plan to change this to use <details> or such in the near future. There are lots of minor known issues still left, but none that I thought was important enough that it needs to delay review. Feedback can be sent to the whatwg list, CCing me, with [editing] in the subject. (I'm also fine receiving feedback on public-html or public-webapps, but I don't know if the chairs would be okay with that, since it's off-topic.) I should be available to respond to all feedback promptly at least through the end of August. After that, I can't make specific guarantees about my availability, but I do plan to continue maintaining the spec in the long term.
Posted in WHATWG | 3 Comments »
Next week Wednesday, August 3, the W3C HTML5 Last Call review period ends. Consider taking another look and giving some feedback!
Here is a quick rundown of what happened last week:
- The proposed
download attribute made it into the HTML specification. Specify it on an a element to force the referenced resource to be downloaded rather than navigated towards.
- The WebApps WG published a first draft of The From-Origin Header. It allows resources to declare they are unavailable within an embedding context. E.g. to prevent bandwidth leeching.
- The DOM Core draft now defines the
NodeIterator and TreeWalker features: Traversal chapter in DOM Core. These features have existed for ages, but details were not defined thus far.
- In a quest to define
window.find() Ian suggests that maybe it ought to be dropped. If you need it, speak up!
- In the light of a small vulnerability with allowing the
base element in the body element, we are taking another look at it. Because well, all your base are belong to us.
Since the summer causes a slowdown of everything standards, the next WHATWG Weekly is in two weeks.
Posted in WHATWG | Comments Off on WHATWG Weekly: End of HTML5 Last Call