Re: [whatwg] Give guidance about RFC 4281 codecs parameter
Hi Charles, Dave,
On 4/10/07, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote:
Hello,
On 4/9/07, Dave Singer [EMAIL PROTECTED] wrote:
* Theora video and Vorbis audio in Ogg container. (application/ogg; .ogg)
* Dirac video and Vorbis audio in Ogg container. (application/ogg; .ogg)
* Theora video and Vorbis audio in Matroska container. (video/x-matroska;
.mkv)
* Dirac video and Vorbis audio in Matroska container. (video/x-matroska;
.mkv)
My understanding is that the Ogg container is 'specific' to these codecs,
and therefore the codecs parameter is not needed. But I am not an Ogg or
Matroska expert; perhaps they could chime in?
No. The containers are independent of the codecs put inside.
However, whether software, that supports Ogg or Matroska containers will
actually be able to play other codecs is another issue altogether.
Yes, the codecs are independent of the containers.
Xiph is using multiple MIME types to deal with this situation.
* application/ogg (http://www.rfc-archive.org/getrfc.php?rfc=3534)
provides for the container format, basically with any codecs included:
this could e.g. be Theora/Vorbis inside Ogg or Dirac/Vorbis inside
Ogg, but is not restricted to this.
Xiph has defined a Skeleton track for Ogg files through which the
MIME type of the contained codecs is specified at a known location in
the header of the Ogg file. Thus, a Ogg Theora/Vorbis File with a
skeleton track will have a MIME type of application/ogg and contain
two tracks with video/x-theora and audio/x-vorbis as the MIME types.
Xiph encourages everyone to use the Skeleton track in all future
created Ogg files. Skeleton is built into a standard Ogg container
format (as defined in RFC 3533
http://www.rfc-archive.org/getrfc.php?rfc=3533) and thus Ogg files
with Skeleton are compatible with Ogg files without Skeleton.
* audio/x-vorbis is used to specify the vorbis codec. This is of
particular importance in rtp/rtsp streaming applications.
* video/x-theora is particularly used to specify the theora codec.
The community has also been seen to use these specifications:
# audio/x-vorbis+ogg for Ogg Vorbis files
# video/x-theora+ogg for Ogg Theora/Vorbis files
though Xiph is not supportive of these.
Recent discussion at Xiph around http://www.ietf.org/rfc/rfc4281
suggests the use of the following parameters:
# application/ogg; codecs=theora, vorbis for Ogg Theora/Vorbis files
# application/ogg; codecs=theora, speex for Ogg Theora/Speex files
# application/ogg; codecs=vorbis for Ogg Vorbis files
and also use the disposition parameter:
# application/ogg; disposition=moving-image; codecs=theora, vorbis
# application/ogg; disposition=sound; codecs=speex
Skeleton and the use of these MIME parameters should make things clear
for the application developers.
We did have the discussion over profiles of these codecs; I
understand profiles
are not used, but I am still unclear as to which of the following is true:
a) features are never added to the bitstreams, so any release of the decoder
will decode bitstreams made by any release of the encoder (modulo bugs);
b) the decoder release needed is signalled somehow in the bitstream
('need at
least the April 2005 release or later to decode this file')
c) neither of the above are true, it's left to the users to stay up
to date, and if
they don't, then, well, that's their problem.
In reply to this: Xiph has very carefully created and frozen (1st June
2004) a definition of the theora codec bitstream format, which should
be persistent for a while to come. So, while it is possible that there
may be new features added, it is not currently a consideration. There
are still multiple rounds of software optimisation possible to theora
encoders before they will require a change to the bitstream format.
For the case of a bitstream format change, there is version
information in the header of a theora bitstream. Major and minor
version numbers are being used similarly to the way that *nix library
version numbers work - anything with a minor change is backwards
compatible, but a major change may not be. So, if a major version
number change was to occur with theora, a new MIME type would probably
be required, e.g. video/x-theora2.
I hope this answers the question?
Best Regards,
Silvia.
Re: [whatwg] Attribute for holding private data for scripting
On Mon, 09 Apr 2007 21:37:31 +0200, Jon Barnett [EMAIL PROTECTED]
wrote:
I can think of two possibilities.
One would be to allow the param element as a child of any element (or any
block level element?)
http://www.whatwg.org/specs/web-apps/current-work/#param
And then make an attribute of HTMLElement called params
readonly attribute HTMLCollection params;
Where params is a collection of HTMLParamElements that are children (not
further descendants) of that element.
That would make this:
div id=fooparam name=answer value=42Some more content/div
easy to access via JavaScript:
var foo = document.getElementById(foo);
if(foo.params['answer'] == 42) {
// it is!!
}
The only other possibility I can think of would be an HTML attribute
called
params that would be a list of tokenized name value pairs, but that
sounds
even hairier to implement.
Or allow any attribute that starts with x_ or something (to prevent
clashing with future revisions of HTML), as private attributes.
div id=foo x_answer=42Some more content/div
var foo = document.getElementById(foo);
if(foo.getAttribute(x_answer) == 42) {
// it is!!
}
UAs wouldn't have to implement anything new using this proposal. The
.param attribute you proposed doesn't work in today's browsers and so
param/param= would be a lot harder to work with in practice.
(I don't feel strongly either way about allowing private attributes,
although I have to admit I have abused class/title for scripting purposes
in the past where private attributes would have been more elegant and
possibly more performant, FWIW.)
--
Simon Pieters
Re: [whatwg] Attribute for holding private data for scripting
On 4/10/07, Simon Pieters [EMAIL PROTECTED] wrote: Or allow any attribute that starts with x_ or something (to prevent clashing with future revisions of HTML), as private attributes. Instead of starts with x_, how about contains a colon? A conformance checker could ensure that there is a corresponding xmlns declaration that applies here, and possibly even do additional verification if it recognizes the namespace. An HTML5 parser would, of course, recover from references to undeclared namespaces, placing the entire attribute name (including the prefix and the colon) into the DOM in such situations.
Re: [whatwg] Give guidance about RFC 4281 codecs parameter
At 18:33 +1000 10/04/07, Silvia Pfeiffer wrote:
Recent discussion at Xiph around http://www.ietf.org/rfc/rfc4281
suggests the use of the following parameters:
# application/ogg; codecs=theora, vorbis for Ogg Theora/Vorbis files
# application/ogg; codecs=theora, speex for Ogg Theora/Speex files
# application/ogg; codecs=vorbis for Ogg Vorbis files
sounds good;
and also use the disposition parameter:
# application/ogg; disposition=moving-image; codecs=theora, vorbis
# application/ogg; disposition=sound; codecs=speex
what is the 'disposition' parameter?
We did have the discussion over profiles of these codecs; I
understand profiles
are not used, but I am still unclear as to which of the following is true:
a) features are never added to the bitstreams, so any release of the decoder
will decode bitstreams made by any release of the encoder (modulo bugs);
b) the decoder release needed is signalled somehow in the bitstream
('need at
least the April 2005 release or later to decode this file')
c) neither of the above are true, it's left to the users to stay up
to date, and if
they don't, then, well, that's their problem.
In reply to this: Xiph has very carefully created and frozen (1st June
2004) a definition of the theora codec bitstream format, which should
be persistent for a while to come. So, while it is possible that there
may be new features added, it is not currently a consideration. There
are still multiple rounds of software optimisation possible to theora
encoders before they will require a change to the bitstream format.
For the case of a bitstream format change, there is version
information in the header of a theora bitstream. Major and minor
version numbers are being used similarly to the way that *nix library
version numbers work - anything with a minor change is backwards
compatible, but a major change may not be. So, if a major version
number change was to occur with theora, a new MIME type would probably
be required, e.g. video/x-theora2.
I hope this answers the question?
Yes, at least for Theora. Thank you!
--
David Singer
Apple Computer/QuickTime
Re: [whatwg] Give guidance about RFC 4281 codecs parameter
On Tue, Apr 10, 2007 at 11:21:10AM -0700, Dave Singer wrote: # application/ogg; disposition=moving-image; codecs=theora, vorbis # application/ogg; disposition=sound; codecs=speex what is the 'disposition' parameter? The idea of a 'disposition-type' is to mark content with presentational information. See the Content-Disposition Header for MIME described in RFC 1806 for an early example. The specific proposal Silvia mentioned is to add the content- disposition to the media-type to inform parsers of the general nature of the content, even if they don't recognize the specific codecs. The allowed values for the 'disposition' label come from the Dublin Core set. This is not part of RFC 4281, and as far as I know hasn't been formally documented with the IETF, but we do think it's a good idea. This arose out of the need to discover or record audio vs audiovisual status for media files in the context of routing to the proper playback application, which has been particularly contentious with the Ogg container since we have insisted that such distinctions be made via metadata or file inspection instead of defining distinguishing filename extensions has has been done with other containers. (MooV is perhaps another example.) In terms of user presentation, audio vs video vs text vs still image is the important distinction, while the 'codecs' parameter answers the more technical question of what playback capabilities are necessary. A video/ or audio/ markup element already describes this adequately, but it is a larger issue for media handling on the web. Charles wrote a more detailed proposal in the context of RSS media syndication, which is where I first heard of the idea. http://changelog.ca/log/2005/08/21/rss-disposition-hinting-proposal We're essentially suggesting his proposal be extended to (media) containers in general. -r
Re: [whatwg] Attribute for holding private data for scripting
On Tue, 10 Apr 2007 20:21:27 +0200, Sam Ruby [EMAIL PROTECTED] wrote: Or allow any attribute that starts with x_ or something (to prevent clashing with future revisions of HTML), as private attributes. Instead of starts with x_, how about contains a colon? A conformance checker could ensure that there is a corresponding xmlns declaration that applies here, and possibly even do additional verification if it recognizes the namespace. An HTML5 parser would, of course, recover from references to undeclared namespaces, placing the entire attribute name (including the prefix and the colon) into the DOM in such situations. * That would be confusing to people familiar with XML; * It would hinder the ability to exchange scripts between HTML and XML; * It would create more differences between XML and HTML where less seems to be desired (trailing slash allowed, etc.). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Attribute for holding private data for scripting
On 4/10/07, Sam Ruby [EMAIL PROTECTED] wrote: Instead of starts with x_, how about contains a colon? A conformance checker could ensure that there is a corresponding xmlns declaration that applies here, and possibly even do additional verification if it recognizes the namespace. An HTML5 parser would, of course, recover from references to undeclared namespaces, placing the entire attribute name (including the prefix and the colon) into the DOM in such situations. I like the idea of prefixed attributes for that purpose. This shouldn't be an issue for text/html parsing. http://www.whatwg.org/specs/web-apps/current-work/#attributes0 That section doesn't explicitly allow colons in attribute names. A provision would need to be made for that, but only for text/html parsing As for text/xml parsing, those prefixed attributes would need to belong to a namespace. Should there be a specific URI designated for these attributes - I suspect that allowing the author to make up his own namespace URNs whimsically is bad. Is there already a namespace URI for this purpose (e.g. urn:private)? Possibly causes more problems than it solves. What about any attribute that starts with _ as opposed to x_? I'm messing with designMode in Firefox right now, and it appears Firefox adds an attribute called _moz_dirty to certain elements for internal scripting purposes. Are there cases where other browsers do something similar? Is there already a convention in some applications similar to the -xxx- convension in CSS for this purpose?
Re: [whatwg] Attribute for holding private data for scripting
On 4/10/07, Anne van Kesteren [EMAIL PROTECTED] wrote: On Tue, 10 Apr 2007 20:21:27 +0200, Sam Ruby [EMAIL PROTECTED] wrote: Or allow any attribute that starts with x_ or something (to prevent clashing with future revisions of HTML), as private attributes. Instead of starts with x_, how about contains a colon? A conformance checker could ensure that there is a corresponding xmlns declaration that applies here, and possibly even do additional verification if it recognizes the namespace. An HTML5 parser would, of course, recover from references to undeclared namespaces, placing the entire attribute name (including the prefix and the colon) into the DOM in such situations. * That would be confusing to people familiar with XML; * It would hinder the ability to exchange scripts between HTML and XML; * It would create more differences between XML and HTML where less seems to be desired (trailing slash allowed, etc.). How so? The idea is to place these attributes into the DOM the same way as they would be when parsed with an xml parser, for the cases where the data happens to be namespace valid. And to do what you would expect in the cases where, for example, attribute values aren't quoted. And to follow the html5 credo of recover at all cost in cases where what the user entered doesn't conform. This would of course need to be spec'ed, AND compared against common usage, AND prototyped; I simply ask that it not be rejected out of hand. - Sam Ruby
Re: [whatwg] Attribute for holding private data for scripting
On Tue, 10 Apr 2007 22:41:12 +0200, Sam Ruby [EMAIL PROTECTED] wrote: How so? I missed the part where you wanted to change existing HTML parsers. I thought Hixie pointed out earlier (by means of examples) why we can't have namespace parsing in HTML. I suppose we can discuss it again... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Attribute for holding private data for scripting
Anne van Kesteren wrote: On Tue, 10 Apr 2007 22:41:12 +0200, Sam Ruby [EMAIL PROTECTED] wrote: How so? I missed the part where you wanted to change existing HTML parsers. I thought Hixie pointed out earlier (by means of examples) why we can't have namespace parsing in HTML. I suppose we can discuss it again... It is a recurring pattern. The first instance was we can't allow trailing slashes in tags, which was followed up by a carefully crafted and narrow set of exceptions, which was met with that works and was adopted. So... while it is clearly true the full extent of XML namespames will never be supported in HTML5 (and for good reason), namespace qualified attributes allow extensibility in ways that prevent collisions. One of the first questions that would need to be answered: are there any existing documents on the web which would be broken if the name placed into the DOM for attributes with names containing a colon, with an apparent prefix, and one that matched an enclosing xmlns: declaration were to be changed? - Sam Ruby
Re: [whatwg] Attribute for holding private data for scripting
On Tue, 10 Apr 2007 23:14:16 +0200, Sam Ruby [EMAIL PROTECTED] wrote: I missed the part where you wanted to change existing HTML parsers. I thought Hixie pointed out earlier (by means of examples) why we can't have namespace parsing in HTML. I suppose we can discuss it again... It is a recurring pattern. The first instance was we can't allow trailing slashes in tags, which was followed up by a carefully crafted and narrow set of exceptions, which was met with that works and was adopted. Whether or not trailing slashes are allowed doesn't affect parsers in existing browsers or any other parsers compatible with the web for that matter. They merely affect conformance. This contrary to what you're suggesting here (again). So... while it is clearly true the full extent of XML namespames will never be supported in HTML5 (and for good reason), namespace qualified attributes allow extensibility in ways that prevent collisions. One of the first questions that would need to be answered: are there any existing documents on the web which would be broken if the name placed into the DOM for attributes with names containing a colon, with an apparent prefix, and one that matched an enclosing xmlns: declaration were to be changed? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Sequential List Proposal
On 4/8/07, Elliotte Harold [EMAIL PROTECTED] wrote: Michel Fortin wrote: So I propose a sl element (sequential list) which can be used to replace dialog as well as other things. The proposal can be found here: Sounds a little redundant with ol (ordered list). Also sounds needlessly confusing and hard to explain. I'm not sure we really need dialog, but at least it's simple and obvious to explain to people what it means. The more abstract and generic we get the harder this becomes. Concreteness is underrated among software developers, but widely appreciated by other users. I think the dialog example is a retrograde step. The olliciteq|blockquote pattern seems much better than redefining dt and dd, which will confuse XOXO parsers that try to be Postelian. Did I miss some reasoning here?
Re: [whatwg] List captions
On 4/6/07, Elliotte Harold [EMAIL PROTECTED] wrote: Andy Mabbett wrote: How often do we see something like: pAnimals:/p ul liCat/li liDog/li liHorse/li liCow/li /ul This would be more meaningful as: ul caption=Animals liCat/li liDog/li liHorse/li liCow/li /ul No, the caption should be displayed to all users. That means it needs to be element content, not an attribute value. Just maybe ul captionAnimals/caption liCat/li liDog/li liHorse/li liCow/li /ul Seems to me that what you want semantically is: dl dtAnimals/dt ddCat/dd ddDog/dd ddHorse/dd ddCow/dd /dl or maybe dl dtAnimals/dt ddul liCat/li liDog/li liHorse/li liCow/li /ul/dd /dl if you're feeling XOXO-esque
Re: [whatwg] base versus xml:base
In mozilla we currently don't allow relative URIs in the href at all. If the uri is relative it is ignored. This is per HTML4, and I think it would be ok for HTML5 to say the same. Alternatively it could say that it should be relative to the URI used to retrieve the base element. In most cases the URI of the document. Note that the current text isn't implementable since it says that relative uris in base should be resolved against the base uri document, but the base element modifies that base uri so there is a circular dependency. / Jonas
Re: [whatwg] Give guidance about RFC 4281 codecs parameter
On Apr 10, 2007, at 11:58 AM, Ralph Giles wrote: On Tue, Apr 10, 2007 at 11:21:10AM -0700, Dave Singer wrote: # application/ogg; disposition=moving-image; codecs=theora, vorbis # application/ogg; disposition=sound; codecs=speex what is the 'disposition' parameter? The idea of a 'disposition-type' is to mark content with presentational information. See the Content-Disposition Header for MIME described in RFC 1806 for an early example. Wouldn't it be simpler to use video/ogg and audio/ogg as the base types here? That would already tell you the intended disposition. The specific proposal Silvia mentioned is to add the content- disposition to the media-type to inform parsers of the general nature of the content, even if they don't recognize the specific codecs. The allowed values for the 'disposition' label come from the Dublin Core set. This is not part of RFC 4281, and as far as I know hasn't been formally documented with the IETF, but we do think it's a good idea. It seems redundant with the video/ and audio/ base types, and adding such a feature just to make the point that the Ogg container is universal seems like a stretch. This arose out of the need to discover or record audio vs audiovisual status for media files in the context of routing to the proper playback application, which has been particularly contentious with the Ogg container since we have insisted that such distinctions be made via metadata or file inspection instead of defining distinguishing filename extensions has has been done with other containers. (MooV is perhaps another example.) File inspection is not really workable for content coming from the web that might be sent to an external app, so I think the Ogg community should reconsider this stance on distinguishing file types by primary use. In terms of user presentation, audio vs video vs text vs still image is the important distinction, while the 'codecs' parameter answers the more technical question of what playback capabilities are necessary. And indeed, MIME already has audio/, video/, text/ and image/ base types to make this very distinction. It seems unhelpful to invent a second way to say the same thing. Regards, Maciej
Re: [whatwg] Give guidance about RFC 4281 codecs parameter
On 4/11/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Apr 10, 2007, at 11:58 AM, Ralph Giles wrote: On Tue, Apr 10, 2007 at 11:21:10AM -0700, Dave Singer wrote: # application/ogg; disposition=moving-image; codecs=theora, vorbis # application/ogg; disposition=sound; codecs=speex what is the 'disposition' parameter? The idea of a 'disposition-type' is to mark content with presentational information. See the Content-Disposition Header for MIME described in RFC 1806 for an early example. Wouldn't it be simpler to use video/ogg and audio/ogg as the base types here? That would already tell you the intended disposition. Please note that rfc4281 also mentions the problem that video/* bucket types could have audio only included in them: With each bucket type, a receiving agent only knows that it has a container format. It doesn't even know whether content labeled video/3gpp or video/3gpp2 contains video; it might be audio only, audio and video, or video only. Therefore, the video/* type does not clearly indicate which application would be most suitable to be used with such a contant type. Ogg is more pragmatic in this respect: application/ogg is for the bucket type video/x-theora for the video codec stream (no audio) audio/x-vorbis for the audio codec stream Neither video/x-theora nor audio/x-vorbis actually tell you in what container (bucket) your stream comes. The specific proposal Silvia mentioned is to add the content- disposition to the media-type to inform parsers of the general nature of the content, even if they don't recognize the specific codecs. The allowed values for the 'disposition' label come from the Dublin Core set. This is not part of RFC 4281, and as far as I know hasn't been formally documented with the IETF, but we do think it's a good idea. It seems redundant with the video/ and audio/ base types, and adding such a feature just to make the point that the Ogg container is universal seems like a stretch. This arose out of the need to discover or record audio vs audiovisual status for media files in the context of routing to the proper playback application, which has been particularly contentious with the Ogg container since we have insisted that such distinctions be made via metadata or file inspection instead of defining distinguishing filename extensions has has been done with other containers. (MooV is perhaps another example.) File inspection is not really workable for content coming from the web that might be sent to an external app, so I think the Ogg community should reconsider this stance on distinguishing file types by primary use. I totally agree - file inspection is not workable in many cases and therefore the MIME type has to indicate all of this information: the bucket type, the contained codecs, and the suggested type of application to use. In terms of user presentation, audio vs video vs text vs still image is the important distinction, while the 'codecs' parameter answers the more technical question of what playback capabilities are necessary. And indeed, MIME already has audio/, video/, text/ and image/ base types to make this very distinction. It seems unhelpful to invent a second way to say the same thing. rfc4281 and many other digital media bucket formats show that this is not an Ogg-only problem. Since multimedia comes in containers (buckets) in order to serialise what is essentially time-parallel data, there will always be a problem to describe both the container and the containing type of data. Since neither theora nor vorbis can stand on their own without a container format (such as rtsp or ogg), video/x-theora or audio/x-vorbis cannot indicate anything. They only make sense in context. And the same applies, btw, to streaming text or images that are part of a multimedia application. It's not as simple as dividing the world into files of type application (sw), audio, video, text and images. This simplistic world view has been overtaken by reality a long time ago. Best Regards, Silvia.
Re: [whatwg] Attribute for holding private data for scripting
On Apr 10, 2007, at 2:14 PM, Sam Ruby wrote: Anne van Kesteren wrote: On Tue, 10 Apr 2007 22:41:12 +0200, Sam Ruby [EMAIL PROTECTED] wrote: How so? I missed the part where you wanted to change existing HTML parsers. I thought Hixie pointed out earlier (by means of examples) why we can't have namespace parsing in HTML. I suppose we can discuss it again... It is a recurring pattern. The first instance was we can't allow trailing slashes in tags, which was followed up by a carefully crafted and narrow set of exceptions, which was met with that works and was adopted. So... while it is clearly true the full extent of XML namespames will never be supported in HTML5 (and for good reason), namespace qualified attributes allow extensibility in ways that prevent collisions. One of the first questions that would need to be answered: are there any existing documents on the web which would be broken if the name placed into the DOM for attributes with names containing a colon, with an apparent prefix, and one that matched an enclosing xmlns: declaration were to be changed? I think the problem here isn't compatibility with existing content, but rather ability to use the feature in new web content while still gracefully handling existing user agents. We wrote up some design principles for the HTML WG based on the WHATWG's working assumptions which might make this point more clear: http://esw.w3.org/topic/HTML/ ProposedDesignPrinciples. While Don't Break The Web is a goal, so is Degrade Gracefully. To give a specific example: say I make my own mjsml prefix with namespace http://example.org/mjsml;. In HTML4 UAs, to look up an mjsml:extension attribute using getAttribute(mjsml:extension). In HTML5 UAs, I'd have to use getAttributeNS(http://example.org/mjsml;, extension). And neither technique would work on both (at least as I understand your proposal). Now, we could extend getAttribute in HTML to do namespace lookup when given a name containing a colon and when namespace declarations are present, but then we would want to do it in XHTML as well. And using the short getAttribute call instead of a longer getAttributeNS with a namespace prefix might be unacceptable to XML fans. Regards, Maciej
Re: [whatwg] Attribute for holding private data for scripting
Maciej Stachowiak wrote: On Apr 10, 2007, at 2:14 PM, Sam Ruby wrote: Anne van Kesteren wrote: On Tue, 10 Apr 2007 22:41:12 +0200, Sam Ruby [EMAIL PROTECTED] wrote: How so? I missed the part where you wanted to change existing HTML parsers. I thought Hixie pointed out earlier (by means of examples) why we can't have namespace parsing in HTML. I suppose we can discuss it again... It is a recurring pattern. The first instance was we can't allow trailing slashes in tags, which was followed up by a carefully crafted and narrow set of exceptions, which was met with that works and was adopted. So... while it is clearly true the full extent of XML namespames will never be supported in HTML5 (and for good reason), namespace qualified attributes allow extensibility in ways that prevent collisions. One of the first questions that would need to be answered: are there any existing documents on the web which would be broken if the name placed into the DOM for attributes with names containing a colon, with an apparent prefix, and one that matched an enclosing xmlns: declaration were to be changed? I think the problem here isn't compatibility with existing content, but rather ability to use the feature in new web content while still gracefully handling existing user agents. We wrote up some design principles for the HTML WG based on the WHATWG's working assumptions which might make this point more clear: http://esw.w3.org/topic/HTML/ProposedDesignPrinciples. While Don't Break The Web is a goal, so is Degrade Gracefully. To give a specific example: say I make my own mjsml prefix with namespace http://example.org/mjsml;. In HTML4 UAs, to look up an mjsml:extension attribute using getAttribute(mjsml:extension). In HTML5 UAs, I'd have to use getAttributeNS(http://example.org/mjsml;, extension). And neither technique would work on both (at least as I understand your proposal). Here's a page I constructed, and tested on Firefox: http://intertwingly.net/stories/2007/04/10/test.html This page is meant to be served as application/xhtml+xml. Can you test it and see what results you get? Then lets discuss further. BTW, I intentionally don't have a completed proposal at this point. We need to explore what works and what doesn't work further. Now, we could extend getAttribute in HTML to do namespace lookup when given a name containing a colon and when namespace declarations are present, but then we would want to do it in XHTML as well. And using the short getAttribute call instead of a longer getAttributeNS with a namespace prefix might be unacceptable to XML fans. Regards, Maciej - Sam Ruby
Re: [whatwg] Sequential List Proposal
Kevin Marks wrote: I think the dialog example is a retrograde step. The olliciteq|blockquote pattern seems much better than redefining dt and dd, which will confuse XOXO parsers that try to be Postelian. Did I miss some reasoning here? Fictional dialogs don't involve the excerpt and citation of external sources, which is what q/blockquote and cite are properly for. Given the HTML4 spec's own use of dt and dd, it's far from clear that any redefinition is involved. That isn't to suggest that dt and dd are optimal however. -- Benjamin Hawkes-Lewis
