Re: [whatwg] Apply script.defer to internal scripts
On 27/03/07, Kristof Zelechovski [EMAIL PROTECTED] wrote: 3.17.1. The script element specification says: defer (if the src attribute is present) async (if the src attribute is present) I understand that the async attribute must depend on the src attribute because it is needed and meaningful only when the script element is loaded from an external source; however, the advantage of using the defer attribute is not limited to that case. There is no real advantage to the defer attribute since in HTML4 it is only advisory, the UA is not required to actually defer the script execution, and some implementations only defer it until seeing the next SCRIPT element in the source. Relying on it the way your use case does will work in very few browsers, and specifying this in HTML5 would increase backwards incompatibility for a very minimal gain. -- Hallvord R. M. Steen
Re: [whatwg] Apply script.defer to internal scripts
Your description matches rather ASYNC than DEFER. I do not object ASYNC depending on SRC. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stewart Brodie Sent: Tuesday, April 03, 2007 4:08 PM To: [EMAIL PROTECTED] Subject: Re: [whatwg] Apply script.defer to internal scripts Hallvord R M Steen [EMAIL PROTECTED] wrote: On 27/03/07, Kristof Zelechovski [EMAIL PROTECTED] wrote: 3.17.1. The script element specification says: defer (if the src attribute is present) async (if the src attribute is present) I understand that the async attribute must depend on the src attribute because it is needed and meaningful only when the script element is loaded from an external source; however, the advantage of using the defer attribute is not limited to that case. There is no real advantage to the defer attribute since in HTML4 it is only advisory, the UA is not required to actually defer the script execution, and some implementations only defer it until seeing the next SCRIPT element in the source. Relying on it the way your use case does will work in very few browsers, and specifying this in HTML5 would increase backwards incompatibility for a very minimal gain. My implementation will execute the script immediately if it was inline, and execute it as soon as the whole script is available (obtained from filesystem/network) otherwise. As far as I understood the specification, the DEFER simply indicates to the HTML parser that it can continue parsing the HTML without waiting to see if the script is going to insert additional content - i.e. the script will not use document.write (and friends). I suspect that this facility is most useful when pages include a series of small scripts just containing library functions. Using DEFER permits the browser to load them in parallel rather than in series. I often see auto-generated HTML pages that have a dozen or more SCRIPT elements in a row that have been dumped in there by server-side page generators. -- Stewart Brodie Software Engineer ANT Software Limited
Re: [whatwg] on codecs in a 'video' tag.
Hey Gerv, On Apr 3, 2007, at 5:51 AM, Gervase Markham wrote: Maciej Stachowiak wrote: What I mean is that unlike the case for other browser vendors, it won't cost us anything in patent license fees. Ah, right. So you want MPEG because it gives Apple (and Microsoft, I guess) a financial competitive advantage over other browsers. Why do you have to spin everything in such an inflammatory way? If you are actually trying to make an argument and not just grandstanding you might want to assume some minimum of good faith on our part. Most of your post illustrates reasons why you think Mozilla couldn't implement MPEG-4 codecs. Mostly these are based on speculation about what the actual patent license might say. That might be a reason against having an MPEG-4 requirement, but no one has suggested that, so I won't reply to the parts of your message that argue against doing so. There are some remaining parts to comment on: - They appreciate that there are a wide variety of distribution models; for browsers, and do not want to choose technologies which work only for some of those; Unfortunately, Ogg does not work for some browsers either. What is it about the distribution model of Safari that is incompatible with shipping Ogg? Is distribution model the only kind of reason you consider valid? Of all of the points you put forward, lots were why MPEG4 is good for us, but only one could be construed as saying Ogg does not work for us - and that was the submarine patent point. Is this what you are referring to, or is there another reason specifying Ogg doesn't work for Safari? Patent risk and unsuitability for limited processing power devices. (Which I'm tired of repeating.) Opportunity cost of putting engineering work into a less useful codec vs more useful ones. So, just to be clear: you believe interoperability is best promoted by having no codec specified in the spec? I think if the spec mandates a single codec, that part of the spec will be ignored by at least some parties. The current proposal is for a SHOULD, not a MUST. Do you object to SHOULD as well as to MUST? We're fine with the current spec language. Saying nothing at all would be better, but a SHOULD is fine. I followed up on this thread because you seem to be advocating a mandatory requirement. Can you please explain how you believe not specifying a codec at all promotes interoperability? It doesn't do more or less for interoperability than requiring a codec that some vendors won't actually support. Isn't this basically admitting that Ogg Theora would fail in the market if not legislated in the spec? You assume that, absent legislation in the spec, all of the world's codecs would be competing on a level playing field. That's clearly not the case. Maybe not, but legislating a technically inferior codec with less market adoption doesn't seem like it would be promoting a more level playing field. Regards, Maciej
Re: [whatwg] on codecs in a 'video' tag.
Maciej Stachowiak schrieb: Patent risk and unsuitability for limited processing power devices. (Which I'm tired of repeating.) Opportunity cost of putting engineering work into a less useful codec vs more useful ones. I'd say as H.264 is far more complex technology the risk for submarine patents there may be way higher than for the less complex and rather conventional coding scheme implemented in Theora. However, as Apple already is using H.264 in other products you already decided to take the H.264 submarine risk and I can see you'd prefer not to pile another (although fairly small IMO) risk on top of that. That, however, isn't a very compelling argument for parties that don't already use H.264. Personally I don't see a reason why Apple couldn't simply queue an Ogg Theora component provided by a 3rd party into the QuickTime component download system just like they did for VP3 (which is basically the very same technology just with a buggier implementation) for years. Providing a third party component should make sure Apple is safe if interlectual property claims are made (very unlikely IMO, but it can happen for any coding scheme). If this doesn't put Apple into a safe state I don't see how Apple was able to provide VP3 technology (the Apple QuickTime components page stopped mentioning VP3 a few days ago). As for the limited processing power devices: H.264 is a resource hog and it won't play on many mobile devices that don't happen to have a multimedia DSP (that'd be e.g. PocketPCs, that for sure are an attractive target for WHATWG-enabled browsers). It has been demonstrated that Ogg Theora can be played back on that class of devices. Devices that do play H.264 usually have a H.264-capable DSP - like the Video iPod. That one comes with a Broadcom DSP which is 100% reprogrammable and is well suited for Theora decoding (so I am told). Now, of course that's implementation work, but so is the whole WHATWG spec and I'm sure Broadcom would prefer doing the implementation work over losing customers. Maik Merten
Re: [whatwg] on codecs in a 'video' tag.
Maciej Stachowiak wrote: Maciej Stachowiak wrote: What I mean is that unlike the case for other browser vendors, it won't cost us anything in patent license fees. Ah, right. So you want MPEG because it gives Apple (and Microsoft, I guess) a financial competitive advantage over other browsers. Why do you have to spin everything in such an inflammatory way? If you are actually trying to make an argument and not just grandstanding you might want to assume some minimum of good faith on our part. I really don't think that's spinning - it's just a restatement of what you said. You said [Apple would prefer MPEG because], unlike the case for other browser vendors, we don't have to pay fees., which is pretty much the same as [Apple would prefer MPEG because] other browsers would have to pay fees and we wouldn't - which is a financial advantage. Where's the spin? If you don't want us to read those words at face value and draw the obvious conclusions, then don't list not having to pay fees as an advantage for you of MPEG. If Firefox were GPL only, and there were some Foo Codec which only had GPLed implementations, wouldn't you think it quite rude if I listed MoFo and KDE don't have to implement the codec, whereas proprietary browsers do as a reason for wanting Foo Codec as the standard? Most of your post illustrates reasons why you think Mozilla couldn't implement MPEG-4 codecs. Mostly these are based on speculation about what the actual patent license might say. Is the patent license document available to read, or confidential? If the latter, then that itself is a massive sign that it wouldn't work. How could the license rights be transferable to downstream users of our code if we can't tell them what their rights are? What is it about the distribution model of Safari that is incompatible with shipping Ogg? Is distribution model the only kind of reason you consider valid? No; sorry. We're fine with the current spec language. Saying nothing at all would be better, but a SHOULD is fine. I followed up on this thread because you seem to be advocating a mandatory requirement. I believe my first comment in this thread talked about SHOULD. I haven't mentioned MUST. Although I guess it's fairly academic, because it's now pretty clear that Apple doesn't plan to support Theora unless it's forced to by sites not providing an MPEG alternative, and users complaining. Which is a great shame, because Theora/Dirac is the only chance we have of a single codec across all implementations. If people want to look into it further and make 100% certain, that's fine, but I think it's pretty clear that terms which allowed MPEG4 in Firefox would be no thanks, we don't want any more MPEG revenue terms - and the MPEG-LA would never offer them. Gerv
[whatwg] Section nesting menu and an old HTML 3 friend LH
Oops, somehow the list fell off the reply-to chain. On 4/3/07, Spartanicus [EMAIL PROTECTED] wrote: In the above case both lists belong to the section established by the h1, if the second list should not be in that section then the second list should not be nested within the first. You'd mark it up something like this: h1Car and Bicycle Brands/h1 h2Car/h2 ul liNissan/li liJaguar/li /ul h2Bicycle/h2 ul liRaleigh/li liScott/li /ul HTH On 4/3/07, Tim Connor [EMAIL PROTECTED] wrote: Which is the point to having an lh OR sectioning within lists- there is no way as it is currently specified to have nested headered lists (which DOES come up). Right? Is the official answer that all lists should be flattened to one deep? This has places it obviously doesn't work (like nav menus, sitemaps, and other, less site-design specific). The only reason I came here to bug y'all on this, is I have been doing valid and semantic markup professionally for years now, and been an advocate of such, and I do encounter these situations where the current specs leaves something to be desired. As I see, there is no way to do this (my more complex variation on your example), properly, correct? I intentionally threw in a mish-mash of ways of doing it, so there is more to work with - flattened, as you did, lh's and hn's. We are just supposed to flatten all lists? h1Car and Bicycle Brands/h1 ul lhCar/lh liNissan/li liJaguar/li /ul h2Bicycle/h2 ul lih3Road Bikes/h3/li li ul liRaleigh/li liScott/li /ul /li li ul lhMountain Bikes/lh liSpecialized/li /ul /li /ul
Re: [whatwg] on codecs in a 'video' tag.
I really think that this conversation has morphed from 'should HTML recommend or mandate codecs' into mostly 'why apple should support ogg/theora'. Even the first question is a pretty tangential one to the design of the tag itself, the CSS, and so on. Surely people have comments or questions on other aspects of our proposal? There is new stuff, new ideas, and open areas, all ripe for discussionwe have engineers standing by, eager to refine and improve the video tag design itself... At 13:51 +0100 3/04/07, Gervase Markham wrote: The current proposal is for a SHOULD, not a MUST. Do you object to SHOULD as well as to MUST? I'm not crazy about a SHOULD, no, but we can discuss it later. Can you please explain how you believe not specifying a codec at all promotes interoperability? As I said before, I think you have to distinguish systems interoperability, which is driven by integration specifications, and technology interoperability, which is driven by technology specs. Example: video codec specs don't mandate an audio codec, even though for the most part video support without audio support is not very interesting. But integration specs such as 3GPP PSS, or ISMA 1.0 and 2.0, do mention video and audio codecs, protocols, minimum capabilities, and so on. Integration specs, to be effective, are, alas, more than one-line asides in technology specs. Technology specs should, I believe, stand alone and just document that technology - HTML in this case. Let us assume, for the sake of argument, that different terms would be required in order for MPEG4 to be implementable in free software. Is Apple offering to help approach the MPEG-LA? OK, I am not a lawyer and I do not represent the patent holders, and it is not my job to help build their business. I have enough trouble building ours. However, there are both reference and open-source implementations of MPEG codecs (e.g. x264); generally my (possibly flawed) perception is that it is their use that is subject to license, not their mere existence. But given that we are not suggesting a mandate for MPEG codecs, simply pointing out that - for us and our business - their widespread implementation, and competitive landscape, suit our needs, it doesn't seem very material. At 17:47 +0100 3/04/07, Gervase Markham wrote: Although I guess it's fairly academic, because it's now pretty clear that Apple doesn't plan to support Theora unless it's forced to by sites not providing an MPEG alternative, and users complaining. Which is a great shame, because Theora/Dirac is the only chance we have of a single codec across all implementations. The most prevalent codecs *today* are those in cell phones; heck, Nokia has shipped more digital cameras than anyone else (really). In those phones, H.263 and AMR are almost universal (even 3GPP2, which uses a different voice codec, mandates AMR for MMS interoperability, I believe). I think ogg/theora support in the mobile world (as a specification mandate) is unlikely, so I would disagree that they are the only chance we have of interoperability; the best chance is probably getting as close as possible to the mobile world. At 18:44 +0200 3/04/07, Maik Merten wrote: Personally I don't see a reason why Apple couldn't simply queue an Ogg Theora component provided by a 3rd party into the QuickTime component Alas, that wouldn't be Apple then that was complying, merely that we make it possible for each end-user to make their browser compliant. Devices that do play H.264 usually have a H.264-capable DSP - like the Video iPod. That one comes with a Broadcom DSP which is 100% reprogrammable and is well suited for Theora decoding (so I am told). Now, of course that's implementation work, but so is the whole WHATWG spec and I'm sure Broadcom would prefer doing the implementation work over losing customers. We're back to giving Broadcom (and others) business reasons to implement codecs, yes. -- David Singer Apple Computer/QuickTime
Re: [whatwg] Section nesting menu and an old HTML 3 friend LH
Tim Connor [EMAIL PROTECTED] wrote: As I see, there is no way to do this (my more complex variation on your example), properly, correct? I intentionally threw in a mish-mash of ways of doing it, so there is more to work with - flattened, as you did, lh's and hn's. We are just supposed to flatten all lists? h1Car and Bicycle Brands/h1 ul lhCar/lh liNissan/li liJaguar/li /ul h2Bicycle/h2 ul lih3Road Bikes/h3/li li ul liRaleigh/li liScott/li /ul /li li ul lhMountain Bikes/lh liSpecialized/li /ul /li /ul There are errors in your example code. Leaving the issue of suitability of having list headers appear in the document outline aside for the sake of discussing sectioning nested lists, the way to do what you want would be the following: h1Car and Bicycle Brands/h1 ulCar liNissan/li liJaguar/li /ul h2Bicycle/h2 ul lih3Road Bikes/h3 ul liRaleigh/li liScott/li /ul/li lih3Mountain Bikes/h3 ul liSpecialized/li /ul/li /ul -- Spartanicus
Re: [whatwg] on codecs in a 'video' tag.
Dave Singer schrieb: At 18:44 +0200 3/04/07, Maik Merten wrote: Personally I don't see a reason why Apple couldn't simply queue an Ogg Theora component provided by a 3rd party into the QuickTime component Alas, that wouldn't be Apple then that was complying, merely that we make it possible for each end-user to make their browser compliant. I'd guess that'd be nearly as convenient for the end user. He encounters content encoded in whatever format, a dialog pops up I need to download a codec, sit back and enjoy and few seconds later the Apple customer can access the content in whatever format. I think as we're talking of web video optional codec downloads should just work as well as hardwiring things. If Apple is willing to accept a third party component to enable playback of whatever base format Opera and Mozilla are going to use that'd be a good solution for the interoperability issues. Seeing that Apple accepted the VP3 component in the past to make Apple customers happy (business reason) I have hopes that a similiar solution can be found to make sure Apple users can access web content even if it doesn't happen to use a format QuickTime supports out-of-the-box. In case of Microsoft I guess they'd prefer making their user's life difficult over offering non-Microsoft formats with their download service (did that ever deliver a codec I found useful? No.), but seeing that http://www.apple.com/quicktime/resources/components.html lists coding technologies I never heard of I am optimistic that things can be worked out. This is vastly off-topic, but is there a formalized way for 3rd parties to register their qt components and have them in the download service? If e.g. Xiph.org could negotiate a deal of that sort I'd say the whole codec discussion would loose its significance (and work can go on the core functionality of video) as no matter what codecs Apple chooses to deliver by default things would be interoperable enough with a simple ok, download the codec from the Safari user. Devices that do play H.264 usually have a H.264-capable DSP - like the Video iPod. That one comes with a Broadcom DSP which is 100% reprogrammable and is well suited for Theora decoding (so I am told). Now, of course that's implementation work, but so is the whole WHATWG spec and I'm sure Broadcom would prefer doing the implementation work over losing customers. We're back to giving Broadcom (and others) business reasons to implement codecs, yes. Yes. Business reasons would be the driving force behind that.
Re: [whatwg] Section nesting menu and an old HTML 3 friend LH
Ya, it was fast and ugly - more pseudo mark-up to highlight the questions than anything. Of course, this is how things are *currently* marked up in these situations - it's the only logical way. What I am driving at (very poorly, apparently, so you have my apologies) is that some of us lowly authors DO want some sanctioned way to associate those headers. That's all I am asking. I know how to work with what exists. I also just happen to know that hierarchies best represented by nested lists are not that uncommon in creating web content. Yes, you can make an argument for using hn the whole way through (and those of us that nit-pick how we should most semantically mark-up our content, do debate that), instead of nesting lists, but that seems better suited to when it's at a whole document level, rather than a list within a document. That also makes an outline with indentation (not to mention a true menu) a total pain, and requires a bunch of unnecessary additional css work (the addition of pointless classes, or a bunch of sibling selector work). After all, why else do we have the ability to make nested lists. Can we please have SOME method of strictly, explicitly semantically associating headings within lists. Wether it's bringing back a deprecated element, or defining li/lu/ol as sectioning elements, or some other way, I don't really care. I'm okay with the current usage of a hn within a list - heck, we're all pretty practiced at styling that by now ;). I'm just confirming that there is no specified semantic tie, currently, and asking if that is set in stone. Basically, if we don't have lh, then why shouldn't headings as sectioning/outlining tools be allowed in lists? Am I just being stupid, and missing something? Thanks, Tim
Re: [whatwg] on codecs in a 'video' tag.
Maik Merten schrieb: This is vastly off-topic, but is there a formalized way for 3rd parties to register their qt components and have them in the download service? Oh, didn't look hard enough yet. http://developer.apple.com/quicktime/qtcdform.html Maik Merten
Re: [whatwg] on codecs in a 'video' tag.
On Apr 3, 2007, at 9:47 AM, Gervase Markham wrote: Maciej Stachowiak wrote: Maciej Stachowiak wrote: What I mean is that unlike the case for other browser vendors, it won't cost us anything in patent license fees. Ah, right. So you want MPEG because it gives Apple (and Microsoft, I guess) a financial competitive advantage over other browsers. Why do you have to spin everything in such an inflammatory way? If you are actually trying to make an argument and not just grandstanding you might want to assume some minimum of good faith on our part. I really don't think that's spinning - it's just a restatement of what you said. You said [Apple would prefer MPEG because], unlike the case for other browser vendors, we don't have to pay fees., which is pretty much the same as [Apple would prefer MPEG because] other browsers would have to pay fees and we wouldn't - which is a financial advantage. This isn't the first time you've restated something in what seems like a needlessly inflammatory way. Your earlier message in the thread basically said that unless Apple implements Ogg Theora, we don't actually have a commitment to interoperability. Where's the spin? If you don't want us to read those words at face value and draw the obvious conclusions, then don't list not having to pay fees as an advantage for you of MPEG. The more charitable interpretation would be that this is a lack of disadvantage for Apple, rather than an unfair benefit. Not going to debate this further. We're fine with the current spec language. Saying nothing at all would be better, but a SHOULD is fine. I followed up on this thread because you seem to be advocating a mandatory requirement. I believe my first comment in this thread talked about SHOULD. I haven't mentioned MUST. If the goal of your original was not to elevate the SHOULD requirement to a MUST, but rather to persuade Apple to implement Ogg even though we think we have good reasons not to, then you may want to try a different approach. Also, this list is probably not the right forum for such discussion. Regards, Maciej
Re: [whatwg] on codecs in a 'video' tag.
On Tuesday 2007-04-03 11:52 -0700, Dave Singer wrote: Surely people have comments or questions on other aspects of our proposal? There is new stuff, new ideas, and open areas, all ripe for discussionwe have engineers standing by, eager to refine and improve the video tag design itself... If you want more comments, it would be good to include a URL to get the proposal (potentially a message in the list archive, if that's the best one). I'm not sure where to find it amid the hundreds of messages on the list. The most prevalent codecs *today* are those in cell phones; heck, Nokia has shipped more digital cameras than anyone else (really). In I don't think shipped implementation count is a useful metric here. What matters is the amount of use. I think the average PC is used for a lot more Web browsing than the average high-end cell phone. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgp02zQXsHMVq.pgp Description: PGP signature
Re: [whatwg] on codecs in a 'video' tag.
On Apr 3, 2007, at 2:13 PM, L. David Baron wrote: On Tuesday 2007-04-03 11:52 -0700, Dave Singer wrote: Surely people have comments or questions on other aspects of our proposal? There is new stuff, new ideas, and open areas, all ripe for discussionwe have engineers standing by, eager to refine and improve the video tag design itself... If you want more comments, it would be good to include a URL to get the proposal (potentially a message in the list archive, if that's the best one). I'm not sure where to find it amid the hundreds of messages on the list. Apple's CSS Timed Media Module proposal - http://webkit.org/specs/ Timed_Media_CSS.html Apple's HTML Timed Media Elements proposal - http://webkit.org/specs/ HTML_Timed_Media_Elements.html I'm including Maciej's original message regarding Apple's proposals below for reference. A number of the ideas from Apple's HTML proposal have already been incorporated into the current working draft of Web Applications 1.0. http://www.whatwg.org/specs/web-apps/current-work/, naturally. - Kevin Begin forwarded message: From: Maciej Stachowiak [EMAIL PROTECTED] Date: March 21, 2007 5:08:26 PM PDT To: [EMAIL PROTECTED] List [EMAIL PROTECTED] Subject: [whatwg] Apple Proposal for Timed Media Elements Hello WHAT Working Group, With the recent discussions about the video element, we've decided to post our own proposal in this area. This proposal is a joint effort from the Safari/WebKit team and some of Apple's top timed media experts, who have experience with QuickTime and other media technologies. A number of Apple Engineers will follow and participate in further video discussions, including myself and my colleague Dave Singer, who has represented Apple in a number of media-related standards groups. We started work on these documents before the video element was added to the spec and indeed before Opera made their original proposal. But in the interests of getting them out quickly, we decided to publish what we have, rather than revising the documents to be relative to the current spec. This document is still a work in progress, and I hope together we can refine it and fold it into the Web Apps 1.0 spec. There are a few areas of difference worth highlighting: - Our proposal includes a CSS module, which we will eventually submit to the CSS Working Group. We believe that many aspects of controlling timed media are presentational, and so are best represented in CSS. Although Web Apps 1.0 is not the final destination for this document, we think it makes more sense to consider the whole design at once. - We have included a more thorough set of events and properties which we think are needed to build good custom controller UI. In general, we would like to enable not just current web use cases but also somewhat more advanced uses. - We have included an audio element as well as video. - We have included a mechanism for static fallback based on container type and codec, so that it's possible to choose the best video format for a client even if user agent codec support varies. We will be starting separate threads on these and other key issues. We've posted our current proposals here: CSS Timed Media Module proposal - http://webkit.org/specs/ Timed_Media_CSS.html HTML Timed Media Elements - http://webkit.org/specs/ HTML_Timed_Media_Elements.html We also have a list of areas where we think the proposal could use refinement or additional features, but where we do not yet have a final design to present: http://webkit.org/specs/Timed_Media_Elements-Open_Issues.html Regards, Maciej Stachowiak
Re: [whatwg] on codecs in a 'video' tag.
On Tue, 3 Apr 2007, Kevin Calhoun wrote: A number of the ideas from Apple's HTML proposal have already been incorporated into the current working draft of Web Applications 1.0. http://www.whatwg.org/specs/web-apps/current-work/, naturally. And I'm actively working on incorporating more of them as we speak. I'll be writing a detailed response when I've finished my first draft. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Section nesting menu and an old HTML 3 friend LH
Explicitly semantically: use DD for header, DT as a wrapper for items. It means that a top-level list with a header must be wrapped in a DL for completeness. dl dtSample Menu/dt dd dl dtFile/dt dd ul liNew/li liOpen/li liSave/li liProperties/li liClose/li liQuit/li /ul /dd dtEdit/dt dd ul liCut/li liCopy/li liPaste/li liClear/li liShow Clipboard/li /ul /dd dtHelp/dt dd ul liAbout/li liContents/li liIndex/li liSearch/li /ul /dd /dl /dd /dl HTH Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Connor Sent: Tuesday, April 03, 2007 10:12 PM To: Spartanicus Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Section nesting menu and an old HTML 3 friend LH Ya, it was fast and ugly - more pseudo mark-up to highlight the questions than anything. Of course, this is how things are *currently* marked up in these situations - it's the only logical way. What I am driving at (very poorly, apparently, so you have my apologies) is that some of us lowly authors DO want some sanctioned way to associate those headers. That's all I am asking. I know how to work with what exists. I also just happen to know that hierarchies best represented by nested lists are not that uncommon in creating web content. Yes, you can make an argument for using hn the whole way through (and those of us that nit-pick how we should most semantically mark-up our content, do debate that), instead of nesting lists, but that seems better suited to when it's at a whole document level, rather than a list within a document. That also makes an outline with indentation (not to mention a true menu) a total pain, and requires a bunch of unnecessary additional css work (the addition of pointless classes, or a bunch of sibling selector work). After all, why else do we have the ability to make nested lists. Can we please have SOME method of strictly, explicitly semantically associating headings within lists. Wether it's bringing back a deprecated element, or defining li/lu/ol as sectioning elements, or some other way, I don't really care. I'm okay with the current usage of a hn within a list - heck, we're all pretty practiced at styling that by now ;). I'm just confirming that there is no specified semantic tie, currently, and asking if that is set in stone. Basically, if we don't have lh, then why shouldn't headings as sectioning/outlining tools be allowed in lists? Am I just being stupid, and missing something? Thanks, Tim
Re: [whatwg] on codecs in a 'video' tag.
Maciej Stachowiak wrote: This isn't the first time you've restated something in what seems like a needlessly inflammatory way. Your earlier message in the thread basically said that unless Apple implements Ogg Theora, we don't actually have a commitment to interoperability. Close. Unless Apple implements a codec which is implementable by the other browser vendors, they don't really have a commitment to interoperability would be about it. I didn't mean Theora specifically, although only two freely-implementable-in-free-software codecs have so far been suggested (Theora and Dirac). Again, I deny this is inflammatory. You cannot say both we have a strong commitment to interoperability and we are only going to implement a codec which it is impossible for other browsers to ship. They are contradictory. One or the other has to give. You may dispute the impossible - but if we were trying to mandate a standard which required a patent which was available only to free software, and we told you just make all of Safari open source, that would probably be a lesser level of impossibility than make Firefox closed source (which would be required to allow it to ship MPEG). (Regular reminder: only speaking for myself.) But you are right; this is an impasse, and there's not much point going on. Barring a miraculous change of heart from either the members of the MPEG-LA or from Apple, there will be no standard codec for video across all browsers and platforms. Pity the content authors (well, either them, or the users of minority platforms). Gerv
[whatwg] Section nesting menu and an old HTML 3 friend LH
Ok, I'll stop making a nuisance of myself, now. ;) I forget that you are all probably quite fully aware of all the debate that goes into this sort of thing on various developer specific lists (like css-discuss). I guess that is one more argument for the DL folks. ;) It's always seemed a little odd to nest definitions, but I suppose that is a quibble - you can argue that a heading isn't much different. I'll consider this an authoritative (and googlable) answer for when 5 rolls out. Thanks for your time, Tim
Re: [whatwg] on codecs in a 'video' tag.
On Apr 3, 2007, at 21:52, Dave Singer wrote: OK, I am not a lawyer and I do not represent the patent holders, and it is not my job to help build their business. I have enough trouble building ours. However, there are both reference and open- source implementations of MPEG codecs (e.g. x264); generally my (possibly flawed) perception is that it is their use that is subject to license, not their mere existence. I am not a lawyer, either. However, one can observe that * The developers of Open Source implementations of MPEG-4 family encoders and decoders generally live and work in Europe. With the exception of the France-based VLC project, the people and projects usually aren't based in the worst EPO countries. * Some implementation projects only distribute source, presumably to mitigate the patent litigation risk by not shipping a directly runnable product. * No Linux distributor that has business in the United States ships binaries of Open Source implementations of MPEG-4 family codecs. * In fact, it appears that no notable U.S.-based company distributes GPL-licensed implementations of the MPEG-4 family codecs. (Google runs x264 privately within the company. It does not distribute it. Hence, the distribution provisions of the GPL do not apply. And Google does pay money to MPEG-LA.) * The FAQs of some of these projects suggest that there is precedent of companies getting in trouble with MPEG-LA for trying to embed Open Source implementations of MPEG-4 family codecs in commercial products. * It appears that so far MPEG-LA has not gone after American individuals who obtain implementation from Europe for private use. The conclusion I draw is that MPEG-4 family codecs are unacceptable for Open Source projects that have an overt presence in the United States and that distribute software there. This includes Open Source Web browsers. U.S.-based companies that run Open Source encoders on their servers may be able to do so provided that they pay MPEG-LA and do not distribute the software that they run. The most prevalent codecs *today* are those in cell phones; heck, Nokia has shipped more digital cameras than anyone else (really). In those phones, H.263 and AMR are almost universal (even 3GPP2, which uses a different voice codec, mandates AMR for MMS interoperability, I believe). I think ogg/theora support in the mobile world (as a specification mandate) is unlikely, so I would disagree that they are the only chance we have of interoperability; the best chance is probably getting as close as possible to the mobile world. Stuff that a casual Web author would want to encode for the real Web (not Mobile Web) most likely won't Just Work on today's mobile devices. The ISMA stuff is just unacceptably limited for content that needs to looks like being this year's content on desktops. It wouldn't be unreasonable to expect next-generation devices to work better, though. So much better that they could decode YouTube-quality Theora by the time HTML5 implementations reach mobile devices. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] on codecs in a 'video' tag.
Also sprach Dave Singer: I really think that this conversation has morphed from 'should HTML recommend or mandate codecs' into mostly 'why apple should support ogg/theora'. Even the first question is a pretty tangential one to the design of the tag itself, the CSS, and so on. Surely people have comments or questions on other aspects of our proposal? There is new stuff, new ideas, and open areas, all ripe for discussionwe have engineers standing by, eager to refine and improve the video tag design itself... It's tempting to ask standby crew to spend their idle time adding support for ogg/theora, but I would probably find myself at the receiving end of another 'bad faith' message, so I will not even mention it :-) Seriously, though, I think this group is concerned that having a polished video interface isn't worth much in terms of interoperability unless there is a baseline format. It seems that Mozilla and Opera can be convinced to support a common baseline format (I'm not speaking for either in this message), and that they really would like you guys to join in the quest for a better web. Not just a better video element. Cheers, -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] on codecs in a 'video' tag.
I agree with this. The tag isn't worth much to the Web if it's not interoperable among *all* Web browsers. That includes, unfortunately, Internet Explorer. That is why I think trying to pick a baseline format in the WhatWG is premature. Until the video element moves to the HTML WG and we find out what Microsoft's opinion is on this subject, I'm not really sure what the point is of this codec debate. Even if the browser vendors of the WhatWG all agreed to support Theora tomorrow, Mozilla + Opera + Safari constitute only 20% of total browser market share. That percentage is not even remotely compelling enough for content authors to want to use the video element over proprietary alternatives like Flash. dave ([EMAIL PROTECTED]) seems On Apr 3, 2007, at 9:50 PM, Håkon Wium Lie wrote: Seriously, though, I think this group is concerned that having a polished video interface isn't worth much in terms of interoperability unless there is a baseline format.
