Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior
On 25/03/2015 14:54 , Anne van Kesteren wrote: The only suggestion I have is that instead of having four-argument methods we might want to consider introducing two new methods that take a dictionary. E.g. history.push() and history.replace(). Giving the page more control over the scroll position when navigating makes sense to me. +1 This has the added benefit of getting rid of the second argument wart. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Persistent and temporary storage
On 13/03/2015 21:39 , Nils Dagsson Moskopp wrote:
There exists also an issue of perverse incentives. If the browser
tells an application how much storage it can use, an application
developer is likely to try to use the maximum allowed space.
Sorry but I don't think this makes much sense. I can't think of a
developer ever writing code along the lines of:
if (device.hasLeftOverQuota()) {
// ooh! let's write us some more bytes to disk!
}
else {
// oh well, who needz this? LOL!
}
Quotas are useful to set user expectations. For instance, people who
create sites for periodicals are really interested in allowing their
users to download entire issues offline. It's very helpful if they can
say "you've got enough space for 3 more issues" or "you're short on
space, do you want to remove some older issues".
This could also lead to web apps refusing to run if an user agent
does not report enough space.
Which is completely acceptable. If your app needs to store a large data
set locally, telling the user it won't work upfront is a much better
experience than letting them waste both time and data usage (which can
easily matter a fair bit on mobile) only to fail anyway.
--
Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Obsolete Feature [hgroup]
On 18/02/2015 23:07 , Jukka K. Korpela wrote: I recommend using the validator.nu service rather than the W3C one. They're basically the same but the validator.nu one is closer to the WHATWG spec's requirements than the W3C one. The relationship between the two is somewhat obscure, but it is in that direction. What the different validators check against is really their authors’ idea of what is correct HTML, so we have yet another “standard”, defined very implicitly, and mutable. But it indeed appears to be closer to WHATWG HTML than to W3C HTML5. The bottom line is that validators are just useful tools, at best. All HTML5 validators are experimental software that checks against some rules that have not been disclosed in detail but are supposed to match some idea of “HTML5”. Actually, both http://validator.nu and http://validator.w3.org/nu are the same code base with settings adjusted to account for the variance between specs. The relationship isn't "obscure", the code attempts to implement what's in the spec so barring bugs they're not about "the authors' idea of what is correct HTML", and given that the source is open it's hardly a set of "rules that have not been disclosed in detail". https://github.com/validator/validator -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] hidden attribute useless with display: flex?
On 30/04/2014 13:01 , Anne van Kesteren wrote:
Le 29/04/2014 23:32, David Bruant a écrit :
// CSS:
div{
display: flex;
}
// HTML:
Per spec, the div should be shown right? I imagine there is no way back on
that?
We could change the specification to use display-box instead. That might work.
Isn't that just moving the problem though? If the CSS uses display-box:
contents (or whatever else might get added next) for some reason then
hidden won't work either. Less likely, but still.
Maybe having the default style use both display and display-box might fly?
--
Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Mailing List Archive Link
On 12/11/2013 16:10 , Anselm Hannemann wrote: If you ask me I would like to have a link on bottom of every message to the archived version but at w3c they said it wouldn’t be possible because this needs massive changes in the software. More generally, IIRC the policy with W3C mailing lists is to modify the body of the message as little as possible. That said since all WHATWG messages are archived at the W3C, you can always grab the Message-ID from a message posted here and get to its archive using the MID resolver: http://www.w3.org/mid/ So for instance, your initial post can be found at: http://www.w3.org/mid/eaf52201-ecaf-4f7f-839e-0585c085c...@anselm-hannemann.com If your mail client can be somehow scripted to take advantage of this, you can have it grab the MID to generate a link. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Zip archives as first-class citizens
On 13/09/2013 13:31 , Jirka Kosek wrote: On 13.9.2013 12:10, Robin Berjon wrote: I would rather we figured this out without , but apart from the indirection I reckon this approach has some nice properties and might work if more direct ones don't. Also don't forget that while linking is the hardest part of this ZIP circus there is another missing piece -- normative definition of portable and RF subset of ZIP. SC34 started some initial work on such ZIP profile recently: http://www.itscj.ipsj.or.jp/sc34/open/1855.pdf So if some sort of ZIP packaging spec should to appear then it should reference such subset of ZIP not the full definition of ZIP format from PKWare. This has also been done, perhaps not to a sufficient extent, in Widgets: http://www.w3.org/TR/widgets/#zip-archive -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Zip archives as first-class citizens
On 29/08/2013 15:58 , Simon Pieters wrote: On Thu, 29 Aug 2013 15:02:48 +0200, Anne van Kesteren wrote: On Thu, Aug 29, 2013 at 1:19 PM, Jake Archibald wrote: Causing a network error in existing browsers is a shame. It seems to fail to resolve in IE10. It works in Gecko/WebKit/Blink/Presto: the %! is requested literally. However, both Apache and IIS seems to return 400 Bad Request. That's not exactly promising. Picking something that could occur in paths seems problematic. I'm not sure why it's more problematic than something than could occur in the fragment. For instance, the string "$zip=" is not present at all in http://webdevdata.org/ data set 18/06/2013. So maybe we could use a string like that in the path and have a graceful fallback path in legacy browsers that work in existing servers. That's my preferred approach so far. However I wonder about the precise details. Assuming I'm guessing that the browser would actually just request "/foo.zip" from the server in the same manner that fragments are stripped, right? Somehow the stripping bothers me a bit; for instance, what would Navigation Controller see? I wonder if we couldn't just use the query part for this: src="/foo.zip?!zip/dahut.png">. No stripping is needed (as far as I know servers would normally just serve foo.zip in this case), which simplifies the model. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Zip archives as first-class citizens
On 29/08/2013 15:37 , Boris Zbarsky wrote: On 8/29/13 9:32 AM, Anne van Kesteren wrote: Doing a mixture of sniffing and labeling has not served us very well. We cannot rely solely on sniffing because of CSS and SVG. We can rely solely on a standardized mapping table of extension to Content-Type. Ah, ok, the extension table is standardized, not gotten from the OS? OK, that works. And shockingly enough, that's been done before: http://www.w3.org/TR/widgets/#rule-for-identifying-the-media-type-of-a-file-0 There could be a few things worth pilfering from that document in general. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Zip archives as first-class citizens
On 29/08/2013 14:48 , Anne van Kesteren wrote: On Thu, Aug 29, 2013 at 1:15 PM, Alexandre Morgaut wrote: In the solution mentioned with tag and a "pack:" like scheme I don't think adding a level of indirection is a good idea. I think the added complexity is the reason this proposal failed the last time and I don't see a reason to revive it. Actually, the primary objection I recall from the last round of this was that it did not address the major use case that was being considered then, which was performance. It's a revisit of "Limi Packages" and it would seem that they can 1) be slower than individual files in a fair number of cases and 2) bring between nothing and very little compared to SPDY. Of course, that does not remove the value there is in making Zip first class for reasons other than performance. If we can do it without the above indirection then it clearly is better, but using indirection it is possible to make this work without a new scheme, without changing the URL syntax, and while opening the door to graceful fallback. The basic idea is that you start with this: and then every URL in the document (e.g. ) that's a prefix-match for the link's href gets loaded through the zip. Older browsers will fetch /foo.zip/meow.gif, which the server can trivially detect as an error and handle by sending the content from inside the zip. I would rather we figured this out without , but apart from the indirection I reckon this approach has some nice properties and might work if more direct ones don't. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Proposal: Change HTML spec to allow any arbitrary value for the "name" attribute
On 04/06/2013 12:24 , Simon Pieters wrote: On Tue, 04 Jun 2013 12:03:58 +0200, Robin Berjon wrote: I've seen quite a few. One recent example is bug-assist.js — a script that makes it easy for readers of a document to file bugs about it — that looks for all metadata names that start with "bug." and uses the remainder of the name as parameters to a Bugzilla bug entry. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21916 Yes, I'm well aware. I even have a patch for that bug. It was just the first example that came to mind; meta is often the first thing that developers reach for. If the validation errors on metadata names served a clearly useful purpose I'd suggest waiting it out until using data-* becomes more of a reflex, but that doesn't seem to be the case so the pain inflicted in the meantime doesn't appear to be useful. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Proposal: Change HTML spec to allow any arbitrary value for the "name" attribute
On 04/06/2013 11:08 , Smylers wrote: Michael[tm] Smith writes: Speaking from my perspective as a contributor to development of a conformance checker: In practice, we receive a lot of comments and bug reports from confused/frustrated users who are trying to use values for meta@name that are not registered. Hi Mike. Thanks for sharing your wisdom on this. Could you give some examples of the kinds of names people are using? I've seen quite a few. One recent example is bug-assist.js — a script that makes it easy for readers of a document to file bugs about it — that looks for all metadata names that start with "bug." and uses the remainder of the name as parameters to a Bugzilla bug entry. And do you have an idea which user-agents are acting on those names? I am not aware of specific cases in which the browser is acting on the names, but there are quite a few in which a third-party system is (e.g. when using those as checks that a given person really has access to a given site). The point is often that the person seeing the validity error is not the same person who defined the metadata name. Yes, you can register on behalf of someone else, but it's a hurdle and it's not the right social mechanics. It doesn't seem to buy anyone much, either. I'm interested in whether the tags people are using are meaningless cruft or have useful effects in niche fields. They're not cruft, they're product-specific. In many cases some data-* attributes would be better, but they're not what's used. And as far as the strategy of trying to use the spec and Wiki page as a means to educate them about trying to taking the time to register meta@name values and only use registered values and standard values (those listed in the spec), well, that strategy is not working well. They just want the validator to shut up. How about a validator interface along the lines of: I see you've used a tag. kapow isn't a name that I know about. Are you sure that it's a correct name, and that it's doing something useful in your document? If so, please tell me its purpose here, then I'll know what it's for and I won't complain about it again: __ Then the validator could add a wiki entry for it. Going that far might be a bit much, but if there concern is that typos in names then a warning should do the trick. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] definition not compatible with existing user-agent user interfaces
On 05/04/2013 17:01 , Boris Zbarsky wrote: Having the url of the document end up something like about:srcdoc?abcdef where dereferencing it gives you the right data _may_ be a solution. Is there any reason not to use a Blob URL for this (instead of minting new behaviour in an about URL)? Opening a blob URL in a new tab from a link works in at least Firefox and Chrome, I guess they'd work just the same for those frame UIs. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Fetch: HTTP Authentication
On 14/03/2013 16:57 , Anne van Kesteren wrote: On Thu, Mar 14, 2013 at 4:34 PM, Robin Berjon wrote: People who *do* rely on this (assuming they exist — in this case they probably do somewhere) will find their services broken if we change it. So on the face of things, I get the impression that there's zero cost in keeping things the way they are, and risk in changing them. Sure, I meant for new contexts and maybe some existing contexts, such as workers. Oh, yes, agreed — for anything new this is madness. And I doubt anything recent relies on it, either. Also, for shared workers it's not entirely clear which browsing context you'd prompt in if an importScript() or same-origin XMLHttpRequest happened. I think that's definitely a bug. I think that the lack of interoperability, and the complete inanity of prompting in browsers where it happens, is more problematic in the case of unsafe redirects. There should simply be no prompting there, it makes no sense. It's not just madness, it's different madness everywhere :) -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Fetch: HTTP Authentication
On 14/03/2013 15:59 , Anne van Kesteren wrote: So if the server replies with status 401 and a WWW-Authenticate header that is properly formatted (I did not do detailed syntax checks but e.g. WWW-Authenticate: basicerror does not work) is present, we prompt the user. We do this for ,
Re: [whatwg] asynchronous JSON.parse
On 07/03/2013 23:34 , Tobie Langel wrote:
In which case, isn't part of the solution to paginate your data, and
parse those pages separately?
Assuming you can modify the backend. Also, data doesn't necessarily have
to get all that bulky before you notice on a somewhat sluggish device.
Even if an async API for JSON existed, wouldn't the perf bottleneck
then simply fall on whatever processing needs to be done afterwards?
But for that part you're in control of whether your processing is
blocking or not.
Wouldn't some form of event-based API be more indicated? E.g.:
var parser = JSON.parser();
> parser.parse(src);
> parser.onparse = function(e) { doSomething(e.data); };
I'm not sure how that snippet would be different from a single callback API.
There could possibly be value in an event-based API if you could set it
up with a filter, e.g. JSON.filtered("$.*").then(function (item) {});
which would call you for ever item in the root object. Getting an event
for every information item that the parser processes would likely flood
you in events.
Yet another option is a pull API. There's a lot of experience from the
XML planet in APIs with specific performance characteristics. They would
obviously be a lot simpler for JSON; I wonder how well that experience
translates.
--
Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Including
On 14/11/2012 00:04 , Mark Nottingham wrote: On 14/11/2012, at 4:37 AM, Ian Hickson wrote: (For what it's worth, inclusion in HTML is done using .) Ah. Does that work with older browsers (from the 2005 era onwards)? Nope. But if you want something that's future-enabled you could transition your library into being a shim for seamless iframes. That involves more than inclusion though (see http://benvinegar.github.com/seamless-talk/) so you should probably double-check that seamless is what your use case calls for. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] New URL Standard
On 25/09/2012 01:07 , Glenn Maynard wrote: On Mon, Sep 24, 2012 at 12:30 PM, Tab Atkins Jr. wrote: I suggest just making it a map from String->[String]. You probably want a little bit of magic - if the setter receives an array, replace the current value with it; anything else, stringify then wrap in an array and replace the current value. The getter should return an empty array for non-existing params. You should be able to set .query itself with an object, which empties out the map and then runs the setter over all the items. Bam, every single methods is now obsolete. When should this API guarantee that it round-trips URLs cleanly (aside from quoting differences)? For example, maintaining order in "a=1&b=2&a=1", and representing things like "a=1&b" (no '=') and "a&&b" (no key at all). And round-tripping using ; as the separator instead of &. I mention this because I've seen actual production code (more than once) that relied on this. I have no idea how common it is though. I'm guessing not too much, but probably some since it was in HTML 4.01: http://www.w3.org/TR/html401/appendix/notes.html#h-B.2.2 Of course another option is to just not parse that into key-value pairs in the first place. By the way, it would also be nice for the query part of this API to be usable in isolation. +1 -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Including HTML more directly into SVG
On 11/09/2012 10:15 , Elliott Sprehn wrote: On Mon, Sep 10, 2012 at 4:59 PM, Tab Atkins Jr. wrote: This would be a lot easier if I could somehow invoke the CSS box model inside of SVG, ... This tightly binds the list of element names in SVG to HTML Which isn't that big of a problem. It's a simple matter of staying in sync with the SVG WG, which isn't so hard. and also breaks assumptions inside SVG DOM that HTML5 may depend upon. Indeed SVG already has elements like , and
Re: [whatwg] Node inDocument
On Aug 30, 2011, at 11:40 , James Graham wrote: > On 08/30/2011 10:44 AM, Anne van Kesteren wrote: >> On Tue, 30 Aug 2011 10:38:19 +0200, Jonas Sicking wrote: >>> In general I think it's better to have functions that deal with child >>> lists on Node rather than on Element/Document/DocumentFragment. >>> >>> I think it might still make sense to have inDocument though. That'll >>> allow people to more clearly express what they are actually trying to >>> do, while allowing implementations to write faster code. >> >> If we are going to have Node.contains implementations surely could >> optimize document.contains(node) which seems as clear as node.inDocument >> to me. > > They are different in the case of multiple documents though. But node.ownerDocument.contains(node) isn't. There's no doubt that node.inDocument is less error-prone though. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Thoughts on the media stream bootstrap mechanism
Hi Rich,
On Mar 15, 2011, at 16:24 , Rich Tibbett wrote:
> Secondly, getUserMedia is restricted to only handle audio/video
> streams. In the original proposal there was potential for us to
> connect and disconnect other device classes, such as USB or RS232
> device types.
I'm mostly interested in audio/video, but even considering only those I've been
thinking along similar lines that the current API lacks sufficient hooks for
extensibility. Most notably, some devices might expose ways of controlling them
and exposing those on a GeneratedStream seems clunky.
> The IDL is as follows:
>
> [NoInterfaceObject]
> interface Device {
> const unsigned short WAITING = 0;
> const unsigned short CONNECTED = 1;
> const unsigned short DISCONNECTED = 2;
> const unsigned short ERROR = 3;
> readonly attribute unsigned short readyState;
>
> // event handler attributes
>attribute Function onconnect;
>attribute Function ondisconnect;
>attribute Function onerror;
>
> readonly attribute any data;
>
> void disconnect();
> }
>
> // Specific Device Classes with independent constructors
>
> [Constructor(in DOMString options)]
> interface UserMedia : Device {}
>
> Here's a quick example for obtaining user media:
>
> var m = new UserMedia('audio, video');
> m.onconnect = function( evt ) {
> var ... = evt.target.data; // ... is a GeneratedStream object in a
> UserMedia context
> }
In the examples below I'll stick to the callback-based method of obtaining the
object since that minimises the delta with what's currently in the spec, but I
don't have a strong opinion between that and your proposal. So for clarity,
here's how you get a Device object:
var device;
navigator.getUserMedia("whatever", function (d) { device = d; });
Once you have it, there are a couple improvements that can be made over
GeneratedStream.
• It's an EventTarget. This is primarily for the purpose of listening to
devicemotion and deviceorientation events (they currently only target window,
but that's not a big deal to change). This could work with GeneratedStream, but
it seems more logical to have events for "I moved the camera" (and possibly
others such as "I changed the focal length" or "autofocus acquired at 2.77m")
and for "stream paused" on different objects.
device.addEventListener("deviceorientation", function (ev) {
// ... move that AR code around
}, true);
• It provides an extension point for device control. Say you're streaming from
a camera and you want to take a picture. The chances are high that the camera
can take a much better picture than the frame you can grab off its view-finding
video stream.
// device is a CameraDevice
device.captureStill(function (file) {
// ... got my picture
});
We might not be there yet and would probably want to wait a little, but there's
plenty more that can be added there.
// silly examples
device.zoom = 2;
device.flash = true;
Again, these could go on GeneratedStream but it seems too conflated. Given that
a device exposes a stream, the coding cost is a minimal switch to:
video.src = device.stream;
Additionally, I wonder if it wouldn't be useful to make it possible for the
getUserMedia callback to return an array of devices in one go. If you're making
a 3D movie (or just 3D videoconferencing) you probably want multiple cameras
returned at once (alternatively, it could be a single device exposing two
streams). Likewise if you have a sound setup more advanced than just the one
mike. Of course, the user could effect multiple requests and grant access to
each device one by one, but UI-wise, it's probably a lot simpler to allow her
to do it all at once. Especially considering the following:
1. User wants to add a camera, clicks a button that calls getUserMedia()
2. Infobar of some kind shows, user picks camera source, checks [always allow]
3. User wants to add second camera, clicks the same button: same camera is
picked
4. Failure
Multiple simultaneous inputs isn't science fiction nor is it limited to
professional contexts. I could easily want to use both back and front cameras
on my phone, one with which to film what's going on around me in a documentary,
the other to insert a small view of myself as I comment on what I'm seeing. 3D
home videos are probably not that far around the corner (yes, it scares me
too). It's likely that laptops will ship with arrays of mikes in order to
better figure out where you're talking from (spatially) and eliminate all other
sources — accessing would be sweet.
I don't much care about the syntax, but I guess we could be looking at
something like
navigator.getUserMedia("video multiple", function (devices) {
// ... show each different view
});
And I guess that's enough braindump for today :)
--
Robin Berjon - http://berjon.com/
Re: [whatwg] element, streams and peer-to-peer connections
On May 31, 2010, at 03:01 , James Salsman wrote: > On Sat, May 29, 2010 at 4:57 PM, Mark Frohnmayer > wrote: >> On Thu, May 27, 2010 at 9:26 PM, James Salsman wrote: >>> Would it be appropriate to allow selection between reliable delivery >>> involving delay and unreliable delivery with the shorter delay >>> characteristics of UDP by allowing the user to select between the >>> TCP-based asynchronous HTTP/HTTPS multipart/form-encoded POST of input >>> type=file accept=audio as per http://www.w3.org/TR/device-upload and >>> use UDP for synchronous or asynchronous device element I/O? >> >> I can see use cases for both methods -- a voice mail, server based >> application could use a simple form submit upload, but a live voice >> conferencing app would need real-time access more like in the Capture >> API that the W3C DAP group has published: >> http://www.w3.org/TR/capture-api/ > > It's hard for me to take http://www.w3.org/TR/capture-api/#formatdata > seriously. There are no references to open codecs or codec > parameters; the only audio codec specified is audio/x-wav, which is a > Microsoft-defined union type (RIFF) with a huge number of different > possible instance types, including only a few poor quality open > vocoders and audio codecs by contemporary performance/bandwidth > standards. Where is speex or ogg vorbis? Where are their quality and > bit rate parameters? Why is http://www.w3.org/TR/capture-api/#future > empty when most of the normative sections say, "No exceptions"? Where > is the compatibility with existing file transfer standards? The > security section doesn't contemplate permissions revocation. When a specification is fully complete, mature, and stable, we tend to release it. A rather shocking consequence of this policy is that drafts tend to be incomplete. What's even more outrageous is that sections explicitly marked as "under development" would be lacking in the contemplation of certain aspects department. The next thing you know it might turn out that Céline Dion karaoke sounds bad. Two things you might not know though: 1) the current draft does not look at streamed transmission, merely integration with file upload form controls and / through reuse of the File API (this can be discussed of course, but see below) and 2) we're waiting on input we expect from our friends at Mozilla who have some ideas (but alas little time to write). One interesting suggestion they made was that capture should *not* include a direct way of streaming to a server. Rather, it should solely define how to wire a device to , , , etc. and there ought to be a separate document describe how to capture the output of an element and AV-stream it to a remote endpoint (or save it to disk). The reason for this is that there's no good reason why you wouldn't want to stream (or save) as AV things that originally aren't. There are plenty of use cases from capturing tutorials to the craziest collaborative film-making happening you can think of and including making a video effects editor inside the browser. Naturally, that's where protocol and format noodling would go. Personally, I think that that distinction makes sense. Note that going forward you'll probably want to look at http://dev.w3.org/2009/dap/camera/ rather than the TR snapshots. -- Robin Berjon - http://berjon.com/
Re: [whatwg] id and xml:id
On Apr 12, 2006, at 14:25, Henri Sivonen wrote: On Apr 4, 2006, at 19:35, fantasai wrote: That seems odd. You should be able to say "the content model of this element is anything". http://books.xmlschemata.org/relaxng/relax-CHP-12- SECT-2.html#relax-CHP-12-SECT-2.1 From the spec: "Thus, a RELAX NG schema that is compatible with this feature implies a mapping from element/attribute name pairs onto an ID- type, and hence a mapping from attributes in the instance onto ID- types." ( http://relaxng.org/compatibility-20011203.html ) "Any attribute" with ID-type null on "any element" competes with attribute id with ID-type ID on element foo. That's why the attributes with non-null ID-type would paired with known elements need to be subtracted from the "any" set. Yes, that's is IMHO the single biggest PITA with RNG. I wish that restriction were removed but it seems unlikely. For the SVG Tiny 1.2 RNG I worked around this by having a schema that never mentions the fact that you can have anything from foreign namespaces and using NVDL to express the way in which vocabularies could be mixed. You can look at it at http://www.w3.org/TR/SVGMobile12/ conform.html#ConformingSVGDocuments. I think that a conformance checker / schema should forbid element children of
[whatwg] Announcing the W3C Web APIs and Web Application Formats WGs
Hi folks, as you remember a W3C "WebApps WG" has been discussed here before it was official. Well, now not only is it official but there are two WGs! The Web APIs WG (http://www.w3.org/2006/webapi/) will be working on standard APIs for use within browsers, covering both the rich interaction aspects and the need to finish work on some of the DOM specifications that haven't been touched in too long. The public list is [EMAIL PROTECTED] (sub: [EMAIL PROTECTED] subject=subscribe). The Web Application Formats WG (http://www.w3.org/2006/appformats/) will be producing a binding language based on Mozilla XBL and sXBL (http://www.w3.org/TR/sXBL), as well as a language for user interface (à la XUL). It list is [EMAIL PROTECTED] (sub: public- [EMAIL PROTECTED]). Both groups intend to work closely with the community at large, including the people who work on the WHAT WG specifications. So make sure your voice is heard over there by joining those lists and expressing your opinions! -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: [whatwg] W3C's Rich Web Client Activity and Web Application W/G
Hi Brad, Brad Fults wrote: I would implore the W3C to officially denounce vapor terms such as "DHTML", "Ajax", and "Web 2.0" inside its new WGs. It helps no one when vaguely defined marketing buzzwords are used to describe very specific technologies and methods, much less in a standards-producing environment like the W3C. I doubt the W3C can do much to legislate language, but I also doubt that people in the WG (when formed) will need reminding of that. The terms may be used in elevator pitches, but I'd expect that would be about it. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
