[whatwg] Technical Parity with W3C HTML Spec
Hi, WHATWG folks- As you are probably aware, some differences have arisen between the W3C draft of the HTML5 spec and the larger WHATWG version. In my opinion, the specific technical details of any given feature (which, let's be fair, are often more-or-less arbitrary) is of lesser importance than there being a single definitive version that is consistent between both organizations. The whole point of an open technical standard is to promote interoperability between implementations, and having conflicting or ambiguous specs will not result in that goal. I'm not trying to be political about this, but since W3C and WHATWG are meant to be collaborating, there has to be a certain amount of of flexibility from both sides, for the good of the standard itself, and for readers of the spec. There are a few possible ways to handle this: 1) W3C could match the WHATWG version in all details, with all decisions made by WHATWG 2) WHATWG could match the W3C version in all details, with all decisions made by W3C 3) WHATWG and W3C could maintain different specs with different details, and list the differences with an explanation for each 4) WHATWG and W3C could adopt decisions made in each group, and where there is conflict, decide upon some method of settling the difference of opinion. Options 1 and 2 are obviously both unreasonable. Option 3 results in the problem we have now (though having an explanation for each difference would be an improvement; I don't know of any such wording now). This leaves option 4. W3C has a relatively clear method for resolving conflicts: first, the group tries to settle the issue on the merit of the technical arguments; failing that, the group may hold a poll (with each individual or organization given a single voice); if there is no consensus, the chairs of the group can make a ruling based on the reasoning at hand; if there are still Formal Objections to the results of that poll, the group can escalate the issue up to the Domain Lead, and ultimately all the way up to the W3C Director (who is normally Tim Berners-Lee). Obviously, the strong preference is not to get to the poll stage at all. I don't know of any W3C method for dealing with conflicts between different standards bodies, like W3C and WHATWG, so I think we're in the air here; W3C obviously has no authority over decisions made in WHATWG, but we need to find a way to resolve these conflicts. As I understand it, the editor seems to have final decision-making power in WHATWG, and I don't know of any process for appealing those decisions (assuming you would want to); for the purposes of arbitration between groups, how can we proceed? For the record, here's my suggestion: a) Both WHATWG and W3C should maintain a single definitive HTML5 specification, that is a feature-for-feature match between groups b) For the longer-term WHATWG work, including sections that were once part of the HTML5 spec but were split off into separate specs (Canvas API) or removed (datagrid), there is another "Master Spec" that includes whatever the editor feels is needed in that spec, so long as it doesn't conflict with the HTML5 or related specs c) Where there are technical or political conflicts, WHATWG should decide how to resolve those internally, and how to represent the WHATWG point of view in the W3C HTML WG. I would expect that people differ, so I would expect those different opinions to be represented in liaisons with W3C. I don't have a good answer here, because I think it's up to the WHATWG to decide their own processes, but I hope we agree that we need improvements to how we liaison. Maybe the answer is to have a spokesperson or liaison role, someone respected in the WHATWG community with a reputation for reasonable neutrality? Both Hixie and Maciej have conflicts of interest, as editor and W3C co-chair respectively. Maybe Håkon or David, since they were instrumental in forming WHATWG in the first place? (Sorry I won't be very responsive on this list, I'm actually on vacation and only have sporadic net access.) Regards- -Doug
Re: [whatwg] Speech input element
Hi, Bjorn- Bjorn Bringert wrote (on 5/17/10 9:05 AM): Back in December there was a discussion about web APIs for speech recognition and synthesis that saw a decent amount of interest (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/thread.html#24281). Based on that discussion, we would like to propose a simple API for speech recognition, using a new element. An informal spec of the new API, along with some sample apps and use cases can be found at: http://docs.google.com/Doc?docid=0AaYxrITemjbxZGNmZzc5cHpfM2Ryajc5Zmhx&hl=en. It would be very helpful if you could take a look and share your comments. Our next steps will be to implement the current design, get some feedback from web developers, continue to tweak, and seek standardization as soon it looks mature enough and/or other vendors become interested in implementing it. This is important work, thanks for taking it on and bringing it to a wider discussion forum. Here's a couple of other venues you might also consider discussing it, above and beyond discussion on the WHATWG list: * W3C just launched a new Audio Incubator Group (Audio XG), as a forum to discuss various aspects of audio on the Web. The Audio XG is not intended to produce Recommendation-track specifications like this (though they will likely prototype and write a draft spec for a read-write audio API), but it could serve a role in helping work out use cases and requirements, reviewing specs, and so forth. I'm not totally sure that this is relevant to your interests, but I thought I would bring it up. * The Voice Browser Working Group is very interested in bringing their work and experience into the graphical browser world, so you should work with them or get their input. As I understand it, some of them plan to join the Audio XG, too (specifically to talk about speech synthesis in the larger context), so that might be one forum to have some conversations. VoiceXML is rather different than X/HTML or the browser DOM, and the participants in the VBWG don't necessarily have the right experience in graphical browser approaches, so I think there's an opportunity for good conversation and cross-pollination here. [1] http://www.w3.org/2005/Incubator/audio/ [2] http://www.w3.org/Voice/ Regards- -Doug
Re: [whatwg] idea for .zhtml format #html5 #web
Hi, folks-
Philip Jägenstedt wrote (on 4/2/10 4:36 AM):
On Fri, 02 Apr 2010 15:07:25 +0800, narendra sisodiya
wrote:
just a thought ___
You can view the first webpage create on earth. We have saved our file
from
.txt .rtf .doc and now .odt. I love ODF format (.odt and other things)
but
there is a scope for .zhtml format for document and other purpose.
Basically the idea of zhtml format is to create document/webpage using
HTML5
technology. HTML5 technology with client side can create dynamic webpage
with image video and we can actually use JavaScript to create a dynamic
document. So basically we can create a zip out of all the
html,js,css,images
files and put a extension of .zhtml.
There are many advantage of using zhtml format.
* You can create some good web based software and share it using just one
file.
* Any document create using zhtml will be viewable after 100 years too.
* Server must support .zhtml format so that website can autounzip and
provide underlying files Ex http://localhost/myfile.zhtml/test.html
Disadvantage
* There is no standard over web to make a slideshow Or presentation .
There
are 100 possible ways. So zhtml writers will make their own
conventions but
I believe that this will reach into a equilibrium
* do not know !! but there there will be someone.
Sounds like widgets: http://www.w3.org/TR/widgets/
Yes, this is exactly the motivation behind W3C Widgets (or HTML5
Widgets, if you prefer more buzzwords).
You can gzip up a set of related content, and run it locally with
special permissions. You can digitally sign it, to ensure the integrity
and provenance of the content. You can even run them on the server
referenced from an element in an HTML page. They might be
suitable as a Firefox-like "extensions" mechanism.
I don't think it's defined anywhere, but a browser could choose to save
bundled resources as a self-contained Widget ("File > Save as
Widget..."), which would be a great authoring solution for Widgets.
Regards-
-Doug
