Re: [whatwg] video element proposal
Gervase Markham schrieb: They estimate the increase in download size for a browser shipping Ogg + Theora-ng + Vorbis at 130k. Actually I took the liberty of trying to squeeze a functional set of Ogg decoding libraries into a small footprint (mainly by stripping binaries and using -Os instead of -O2/O3). I now have a 120K archive (tar.bzip2) that features: -rw-r--r-- 1 user users 12K 2007-03-05 14:47 libfishsound.a That's a convenience library to abstract the different Xiph.org audio codecs. My build only supports Vorbis. liboggplay uses this library. -rw-r--r-- 1 user users 8,4K 2007-03-05 16:12 libogg.a The low level Ogg container library. Used by all Ogg codecs. -rw-r--r-- 1 user users 14K 2007-03-05 14:47 liboggplay.a A high level playback library. This makes life easy *and* is making sure A/V sync is working crossplatform (this is not trivial). -rw-r--r-- 1 user users 25K 2007-03-05 14:47 liboggz.a An abstraction library that handles seeking etc. on Ogg streams. Needed by liboggplay. -rw-r--r-- 1 user users 1,7K 2007-03-05 14:47 libtheoracompat.a A small library to expose the usual libtheora API albeit libtheoradec is used. Needed by liboggplay. Once liboggplay can directly use the libtheoradec API it can be skipped. -rw-r--r-- 1 user users 45K 2007-03-05 14:47 libtheoradec.a That's a fast, complete and safe Theora decoder. It'll replace the current reference decoder at one point. -rw-r--r-- 1 user users 136K 2007-03-05 14:47 libvorbis.a The Vorbis decoder. It's a pretty big thing, but I'm told that it contains stuff like precomputed tables that could be computed on startup to reduce the disk footprint. I hope that covers all dependencies. If somebody wanted to dump the convenience libraries and wants to develop his own cross-platform playback system that does seeking and A/V sync you can get away with libvorbisdec, libtheoradec and libogg. Compressed that is 102 K. Maik Merten
Re: [whatwg] audio vs. video
Elliotte Harold schrieb: If we add a video element, should we for the same reasons add an audio element? If not, why not? I'd say that audio and video actually are pretty similiar. They need controls to start playback, to stop playback, to seek, to pause, ... Perhaps there shouldn't be a video element but more something like mediastream audio=true video=true or something like that. Maik Merten
Re: [whatwg] audio vs. video
Also sprach Elliotte Harold: If we add a video element, should we for the same reasons add an audio element? Yes. It seems to me these two cases are similar enough to justify similar treatment. Is there any distinction between the two that would suggest audio is inappropriate while video is appropriate or vice versa? I don't think so. Both deserve to be first-class citizens on the web and they are, therefore, entitled to their own element. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] href attribute
Cheers Matthew - That's probably the most sensible explanation possible. Well done. I'm convinced. Matthew Raymond wrote: carmen wrote: On Fri Mar 02, 2007 at 08:09:10PM +0100, David Håsäther wrote: I don't see the href attribute specified anywhere but the a element in the current Web Applications spec. Is there interest in expanding actionable elements in this way? definitely, as it facilitates the DRY principle of not repeating tags just to fulfll the browser's wishes of only having the href attribute on certain tags.. In that case, why not make abbr an attribute: | li href=http://w3.org; abbr=World Wide Web ConsortiumW3C/li But why stop there? Can't there be a list of abbreviated italicized headers with strong emphasis?... | li href=http://w3.org; h=1 i strong abbr=World Wide Web | ConsortiumW3C/li The desire to save seven characters simply isn't sufficient, especially when the disadvantages are just as great: 1) A full tag is more visible than just the attribute. 2) With DOM tools that represent the document as a tree with each element as a node, you have to examine the properties of each node to find the hyperlinks. 3) The structure of markup encourages people to view elements as having stronger semantics than attributes. Therefore, converting a href into just an attribute is a semantic demotion. (And if you don't think so, consider this: span href.) 4) If you can't see the starting tag, and thus can't see its attributes, then you don't know that the element and its contents are part of a hyperlink, even if the end tag is visible. 5) Using just an attribute can cause restructuring of markup when you need to add content to a hyperlink. Let's say you start with this: | abbr href=http://w3.org; title=World Wide Web Consortium | W3C | /abbr Suppose you now want to add the word Website to the hyperlink: | span href=http://w3.org; | abbr title=World Wide Web ConsortiumW3C/abbr Website | /span Notice that you had to add an element to accommodate the extra content. If you had just used the a element, you'd only need to type Website. Thus a universal |href| attribute promotes fragile markup structure. 6) Legacy browsers will ignore the hyperlink entirely if you use |href| on elements other than a. 7) The ability to make block-level elements hyperlinks promotes bad UI, because it makes it more difficult to perform operations like highlighting and copying text, and because current web users are unaccustomed to hyperlinks on such elements. 8) The attribute may cause confusion on some elements, such as object, blockquote, et cetera. For example, would a web author know the difference between |href| and |cite| on a blockquote element? No, as this would not be backwards-compatible. instead of the generic 'no'. can you implicate situations where a href tag on a non-'a' element confuses the browser? See #6 above.
[whatwg] JavaScipt in output?
Consider this example of the output element from the spec: form p input name=a type=number step=any value=0 * input name=b type=number step=any value=0 = output name=result onforminput=value = a.value * b.value0/output /p /form This is probably an obvious question, but is the language inside the onforminput attribute JavaScript? Is this stated anywhere in the WF2 spec? Are there any restrictions on what you can put in such an attribute? -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] base versus xml:base
On Mon, 05 Mar 2007 22:07:03 +0100, Keryx Web [EMAIL PROTECTED] wrote: It may be that I've implemented this in the wrong way - corrections are welcome - but it seems to me that even though xml:base is legal today, it is **not** supported by UAs. Which makes Anne's proposal, that base should be allowed in both serializations, even more important. There's nu such thing as an xml:base element. It's an attribute. And it is supported although there may be some bugs with dynamic changes etc. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] video element proposal
On Mar 4, 2007, at 16:31, Geoffrey Sneddon wrote: Also note that patents haven't stopped the web in the past (see: GIF). The fact that the Welch patent did not totally wreck the Web and did not cause browsers to drop GIF support should *not* be considered evidence of the harmlessness of patents. In the case of the Welch patent, there were two mitigating factors: 1) The patent (due to drafter incompetence, I presume) did not cover decompression, so it did not affect browsers. 2) It was possible to produce a bit stream that worked with the decompression algorithm but that was not actually compressessed the production method for this kind of bitstream did not infringe on the Welch patent. Some Free Software packages used this method to achieve compatibility while sacrificing actual compression. These mitigating factors are not generalizable, which makes GIF as a case study non-generalizable. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] base versus xml:base
On 5 Mar 2007, at 21:07, Keryx Web wrote: Geoffrey Sneddon wrote: XHTML 1.0/1.1 doesn't allow xml:base, though, so base is the only way to set a base URL within the document. In what way would the XHTML 1.0/1.1 spec **disallow** the use of this element from the xml namespace? It's not *part of* the spec, but that's a different matter, right? xml:lang and xml:base are the actual attribute names – the XML namespace exists so they work within namespace aware parsers (as XML- Names is a separate spec that extends XML) – therefore, it must be explicitly allowed within the DTD (like xml:lang is). - Geoffrey Sneddon
[whatwg] article: do we really need this?
Has there been any extensive discussion of the article element in Web Apps 1.0? It is currently described as: represents a section of a page that consists of a composition that forms an independent part of a document, page, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, or any other independent item of content. It seems sort of wishy washy. Most of the time what I think of as an article is a separate page with its own URL. This use case seems to be handled better by section, perhaps with a role attribute. Maybe a section is less independent than an article, but that's going to be a very fuzzy distinction, and really hard to explain, teach, and validate. Is there some obvious use case for this element? Mostly to me it just seems to needlessly clutter the spec, especially once you consider how it relates to potential sibling sections. I think I'd prefer to just drop it and stick with section. Anyone else feel the same or am I crying in the wilderness again? :-) -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] Distinguishing XML and HTML by content sniffing
Hi Simon, If you load a file from disk, then use any meta information the OS can provide. (I think Linux can store Content-Type information for files.) If the OS relies on file extensions (like Windows does) then use that. Some Linux file systems might potentially be capable of storing extra metadata in extended attributes, but in practice I haven't seen any Linux distributions actually use this functionality for storing the content type of files. This basically leaves us with file extensions, just like Windows. .htm and .html are HTML. I know of lots of HTML documents that start with an XML declaration but are not well-formed if parsed as XML. (For starters, some version of DreamWeaver emitted XML declarations for documents, but did not ensure well-formedness and the result is often not well-formed.) Even if it was well-formed, it probably wasn't tested under XML conditions so it's likely that style sheets and scripts only work correctly under HTML conditions. Given that Prince serves a different niche than most user agents, our users tend to be more likely to use XML with embedded SVG etc., and less likely to run Prince on documents created by DreamWeaver. When Prince is run on a document retrieved over HTTP it obeys the Content-Type header, so that documents on the web will be parsed as HTML. However, it is true that if a document that appears to be XML but actually isn't is downloaded and saved as a file then Prince will try to load it as XML rather than HTML after sniffing the content in the absence of a Content-Type header. The user will then receive error messages if the document is not well-formed. In practice, this case does not seem to arise very often, but if it encourages people to either fix their XML and make it well-formed or stop pretending that their HTML is XML then that doesn't sound like such a bad thing :) If an author authored a document and testing it with Prince, finding that XML-only features work even with a .html file extension, then it is likely that that document would break in browsers (because XML-only features don't work in HTML). This comes back to the thorny issue of how MathML is supposed to work on the web. It seems to require that content be served up as XHTML, which no one does, or that HTML documents contain XML islands, which is not well specified at all. It would be nice if HTML5 could tackle this in a way that makes sense. HTML5 has specified content-sniffing rules, FWIW: http://www.whatwg.org/specs/web-apps/current-work/#content-type-sniffing Yes, these rules never seem to identify a document as being XML, though. See also: http://www.w3.org/Bugs/Public/show_bug.cgi?id=1500 Prince always respects the Content-Type header, and only sniffs document content when no such metadata is available. Best regards, Michael -- Print XML with Prince! http://www.princexml.com
Re: [whatwg] audio vs. video
On Tue, 06 Mar 2007 02:56:31 +1100, Maik Merten [EMAIL PROTECTED] wrote: Elliotte Harold schrieb: If we add a video element, should we for the same reasons add an audio element? If not, why not? I'd say that audio and video actually are pretty similiar. They need controls to start playback, to stop playback, to seek, to pause, ... Perhaps there shouldn't be a video element but more something like mediastream audio=true video=true or something like that. At which point you start heading back to object. It seems we should either take the SMIL approach and make special containers for each kind of media (how many kinds? What is a flash video that has interactive bits? Or an SVG that is mostly video with a few interaction choices? Or interactive SVG with some audio?), or fix object... cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] article: do we really need this?
Elliotte Harold wrote: Has there been any extensive discussion of the article element in Web Apps 1.0? It is currently described as: represents a section of a page that consists of a composition that forms an independent part of a document, page, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, or any other independent item of content. It seems sort of wishy washy. Most of the time what I think of as an article is a separate page with its own URL. This use case seems to be handled better by section, perhaps with a role attribute. Maybe a section is less independent than an article, but that's going to be a very fuzzy distinction, and really hard to explain, teach, and validate. Is there some obvious use case for this element? Mostly to me it just seems to needlessly clutter the spec, especially once you consider how it relates to potential sibling sections. I think I'd prefer to just drop it and stick with section. This element would be extremely useful to someone with a screen reader. It would create an implied UA hook for skip to main content, for one. With multiple postings within a page, it would create a reliable way of skimming the main sections (by reading the first bit of content on each posting), even when there are no headers or when the postings themselves have internal sectioning and headers (especially if those are inconsistent). For printing, the article element would make it easy to cut out extraneous content and print just the main content of a web page. ~fantasai
Re: [whatwg] href attribute
Leons Petrazickis wrote: The sister issue of easy-of-typing is ease-of-reading. Human editing of raw HTML isn't going away. In headier coding disciplines, high readability is prized. Most code -- even HTML code -- will spend a lot more of its time being maintained than being written. Being able to understad things at a glance is important. li class= href= is easier to read than li class=a href=. Hardly. It may be more appealing to the eye for some people, but that's not the same thing as being easier to read. When I'm reading markup, I tend to look for elements first, then the first attribute, et cetera. So, when I'm scanning markup, an I come across the markup above, I would see this: | li class=classname...blah blah=blah-blah-blah bllaaa That's because when you look at enough markup, you train yourself to treat the element name as the most important and search for that first. You only see the attributes when you've already matched on the element. Now, consider the two markup examples above again. Find the hyperlinks: | li class= id=Itemli style=ItemliItemli id=Item | li class= id= style= href=Itemli class= style=Item | liItemli id= style=Itemli class= style= href=Item | li class= id=Itemli style=color:redItemliItemliItem Now try again: | li class= id=Itemli style=ItemliItemli id=Item | li class= id= style=a href=Item/ali class=Item | liItemli id= style=Itemclass= style=a href=Item/a | li class= id=Itemli style=color:redItemliItemliItem To me, the second example is more readable. Now, it may very well be that you have no problem finding the |href| attributes in the first example. However, if that's the case, how can it be harder for you to find the same attribute name in the second? Also note that applications like Mozilla Firefox's DOM Inspector present information in a node tree where attributes are only visible when you click on an element node. Thus, a global |href| attribute would result in hyperlinks being entirely hidden if you haven't specifically clicked on its parent element. To me, the only advantage of a global |href| is that you can use it on block-level elements, and I don't see why a block-level version of a couldn't fill the same use case.
Re: [whatwg] article: do we really need this?
The HyperTextuality Firefox extension I've been writing attempts to work out the most relevant URI for a given piece of content, for bookmarking or quoting. Front pages of blogs, the most important use-case, also pose a particular problem as many blogs don't have an obvious structure (to an automated agent) to distinguish individual articles with a permanent link from the main body of the text (annoyingly, this seems especially true of extremely popular blogs using Moveable Type). article sounds like it would bring somewhat more consistency to that situation. There is a problem in that article might still have no way of referencing it, but the fact that is a discrete piece of content suggests it should. Could include a conformance requirement for article to have a fragment identifier (e.g. for comments) and/or a permalink (e.g. for blog posts)? e.g.: article ... a rel=permalinkhttp://www.example.com/articles/2458/a /article or article id=article-2458-comment-358686 ... /article I'm not sure about the use of address for author information: what happens with anonymous comments, for instance? It might be nice if the spec could define authorship as inherited from parent elements if author is not specified, but we'd need to specify how to mark up an article as anonymous first. addressAnonymous/address isn't a simple solution, since given multiple languages, synonyms, and euphemisms/jokes, that would be automated agent's nightmare. But in any case this points both to another use-case for article and one simple route towards validating it. -- Benjamin Hawkes-Lewis
Re: [whatwg] video element proposal
Maciej Stachowiak wrote: Restricting the types of content that the video element can handle will stifle future innovation, and will likely be ignored by browser vendors who decide they would like to support new formats. It would also be unprecedented relative to type restrictions on other HTML elements. Having a baseline set of formats is something to consider, but the spec should allow supporting any format that can reasonably considered video. The spec could also consider urging /authors/ not to use formats only implemented in one or two browsers and to avoid proprietary formats where open ones are available ... unless we want to allow nesting video elements for fallback? Not that there's anything wrong with nested elements, seeing as we must offer text fallback anyhow, and seeing as the same API would be exposed by each nested level. -- Benjamin Hawkes-Lewis
