Re: [whatwg] Apply script.defer to internal scripts
You do not place a script element after the body element:
3.6.1. The html element
Content model:
A head element followed by a body element.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alexey Feldgendler
Sent: Thursday, March 29, 2007 12:36 AM
To: [EMAIL PROTECTED]
Subject: Re: [whatwg] Apply script.defer to internal scripts
On Tue, 27 Mar 2007 21:49:41 +0200, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
Consider the following example:
script type=text/javascript defer
function ha8validate(p5event) { return true }
document.forms[0].onsubmit = ha8validate
/script
The script embedded here is so short and specific that it makes no sense
relaying it to an external location; however, if the script is not
deferred, the script fails with an exception at run time because the
document body is not constructed yet.
What's wrong with simply placing it after /body?
--
Alexey Feldgendler [EMAIL PROTECTED]
[ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Apply script.defer to internal scripts
On Thu, 29 Mar 2007 09:19:47 +0200, Kristof Zelechovski [EMAIL PROTECTED] wrote: The script embedded here is so short and specific that it makes no sense relaying it to an external location; however, if the script is not deferred, the script fails with an exception at run time because the document body is not constructed yet. What's wrong with simply placing it after /body? You do not place a script element after the body element: 3.6.1. The html element Content model: A head element followed by a body element. Sorry, immediately before /body. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Apply script.defer to internal scripts
On Thu, 29 Mar 2007 13:07:58 +0200, Gareth Hay [EMAIL PROTECTED] wrote: What about the DOMContentLoaded event? It is supported by Mozilla and, apparently, Opera 9. Dean Edwards has a technique to make it work on IE, and jQuery supports it on Safari [1]. Is there any chance DOMContentLoaded will be part of HTML5? imho, doing something like this is a much better solution, again imho. How is this better than putting the script immediately beefore /body, which already works today? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Canvas - globalCompositeOperation
I've added some tests at http://canvex.lazyilluminati.com/tests/tests/index.2d.composite.transparent.html based on the definitions I suggested. Firefox and Safari match the expected results, Opera misses on atop/xor/lighter. (I skipped darker, because it doesn't make sense and I'm hoping it'll just go away...) (The automatic testing may give the wrong answers if your browser has a getImageData that isn't the same as Firefox's (which returns premultiplied alpha) - I believe that's a problem in Firefox and/or the spec, but I'm not looking into it in any detail now.) When I originally said | The calculation of aO must be clamped to the range [0, 1]. that actually should be | The calculation of aO and cO must be clamped to the range [0, 1]. because of e.g. the white lighten white case, where cO can exceed 1. On 28/03/07, ddailey [EMAIL PROTECTED] wrote: I suspect you already are aware of this but in addition to the references you provide the SVG 1.1 reco gives examples of the Porter-Duff composites http://www.w3.org/TR/SVG11/filters.html Thanks, I hadn't thought of looking there. That SVG 1.1 section (feComposite) seems to skip over the issue of actually defining what the operators mean, and refers to the Porter-Duff paper. The SVG 1.2 draft at http://www.w3.org/TR/2004/WD-SVG12-20041027/rendering.html#comp-op-prop does give the equations, and also adds a dozen extra operators, but removes the ability to define your own arithmetic ones. SVG Tiny 1.2 at http://www.w3.org/TR/SVGMobile12/painting.html#CompositingSimpleAlpha appears to get rid of all the compositing except for plain source-over blending, so it's the same as SVG 1.0 at http://www.w3.org/TR/SVG10/masking.html#SimpleAlphaBlending . (I don't know what to conclude from this, except that there presumably isn't a universal consistent convention for what compositing operators should be provided.) It appears that Opera is not handling them properly in SVG either: http://srufaculty.sru.edu/david.dailey/svg/newstuff/filterComposite2.svg It seems to at least do http://www.w3.org/TR/SVG11/images/filters/feComposite.svg quite close to the example rendering (whereas Firefox does nothing except source-over) - the colours are a bit darker, but I don't know if that's an issue with Opera or with the example. David Dailey -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] Apply script.defer to internal scripts
Matthias Bauer wrote: Is there any chance DOMContentLoaded will be part of HTML5? Seems to have been forgotten: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2005-April/003709.html -dean
Re: [whatwg] on codecs in a 'video' tag.
Dave Singer wrote: At 9:48 +0100 28/03/07, Gervase Markham wrote: Dave Singer wrote: Yes. I re-iterate; we have nothing aganist the Ogg or Theora codecs; we just don't have a commercial reason to implement them, and we'd rather not have the HTML spec. try to force the issue. It just gets ugly (like the 3G exception). But that's circular reasoning. We don't have a commercial reason to implement Ogg or Theora, and so we'd rather not have the HTML spec give us a commercial reason. No, writing it into the HTML specification is not a commercial reason. Assuming you have commercial reasons for supporting HTML 5 (which I suspect you do, otherwise you wouldn't be here) then having Ogg specified gives you a commercial reason to support it. If that's not a commercial reason, then what would be a commercial reason? If everyone else implemented it? That's an attempt to force the issue by fiat. But any specification for anything could be described as an attempt to force the issue by fiat. That' just loaded language. Why don't we all just go away and implement what we think is best for HTML 5, and then put a spec together after the fact? Then we wouldn't be forcing any issues, and there would be no fiat. But we all know how well this approach to standards works. No matter what the spec. says, if broad support became a reality, then yes, it may be in our commercial interests. So Apple's strategy is to wait and see what codec everyone else implements, and then implement that one? And at that point there would be many companies using the codec in a money-making way, with 'pockets', and we'd be clearer about the likelihood of IPR challenges. There are plenty of such companies already, as another poster has pointed out. If you have nothing against Ogg or Theora, and your interest in multi-vendor multimedia standards is deep and long-lasting, interoperable, and very open, and other parties have said that a baseline codec for video needs to be open and (as far as can be discerned) patent and royalty-free, then surely your position must one one of the following: - You don't actually want a baseline codec in the spec - i.e. you don't actually have a commitment to interoperability we have a strong commitment to interoperability in each spec. on its own right So what is your plan for promoting interoperability among implementations of video? - You do want a baseline codec in the spec, but you are happy for it to be someone other people can't implement - i.e. you don't actually have a commitment to multi-vendor multimedia standards anyone *can* implement the codecs we implement; they may choose not to, for commercial reasons (e.g. they don't like the license) Oh c'mon, that's a ridiculous definition of the word can. How exactly can the KDE project implement a codec in Konqueror which requires royalties? How can the Mozilla project implement such a codec without removing the redistributability of Firefox? Yes, browsers can implement such codecs if they stop being open source and freely redistributable. Just as the W3C can have lots of cool ideas in their specs if they changed the patent policy to not require royalty-free licences. But most people wouldn't accept that as a reasonable definition of can. Until someone starts using the Ogg family to make money, and in such a way that any possible IPR owners consider it in their business interests to start enforcing their IPR, the situation remains in question. We have nothing against these codecs, but we are not currently feeling like being the guinea-pig... Other posters have commented on this better than I. - we'd an HTML specification which is clear and interoperable on the HTML level, and is in a similar position to the img tag on what may be embedded (it mentions only examples) As another example of specifications requiring support for other specifications, SVG viewers are required to support both JPEG and PNG: http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers And I haven't seen anyone writing standards like Yes, we support SVG, but not the bit which says we need to support JPEG and PNG. Gerv
Re: [whatwg] video element feedback
Henri Sivonen wrote: I've asked about this before but I still don't understand it: Why doesn't Gecko completely ignore the classid? Apart from the fact that this would technically be a spec violation, it actually breaks some pages (because the ActiveX and NPAPI versions of some plug-ins expose different APIs), last I checked. (IIRC, Opera on Mac and Mac IE 5 ignore the classid and dispatch on MIME.) Which fixes pages that don't use a fallback embed, but breaks some others. It's a tradeoff of which exact pages you want to work and how many of them there are... -Boris
[whatwg] Media element typos
Hi, * The IDL for the source element is incorrect. Specifically, the attributes need a name change. * The HTMLMediaElement.currentLoop attribute should be of type unsigned long rather than float. Cheers, -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] on codecs in a 'video' tag.
On Thu, 29 Mar 2007, Gervase Markham wrote: Dave Singer wrote: No, writing it into the HTML specification is not a commercial reason. Assuming you have commercial reasons for supporting HTML 5 (which I suspect you do, otherwise you wouldn't be here) then having Ogg specified gives you a commercial reason to support it. If that's not a commercial reason, then what would be a commercial reason? If everyone else implemented it? A _commercial_ reason would be our customers demand it. Customers in this case would be users, and users would demand it if a big video site started using Ogg Theora. Why don't we all just go away and implement what we think is best for HTML 5, and then put a spec together after the fact? Then we wouldn't be forcing any issues, and there would be no fiat. But we all know how well this approach to standards works. Actually that's pretty much exactly what we're doing with HTML5. No matter what the spec. says, if broad support became a reality, then yes, it may be in our commercial interests. So Apple's strategy is to wait and see what codec everyone else implements, and then implement that one? Everyone's strategy should be to implement what they need to implement. Implementing random stuff without good reason ends up simply bloating your product. anyone *can* implement the codecs we implement; they may choose not to, for commercial reasons (e.g. they don't like the license) Oh c'mon, that's a ridiculous definition of the word can. How exactly can the KDE project implement a codec in Konqueror which requires royalties? How can the Mozilla project implement such a codec without removing the redistributability of Firefox? In both cases, by negotiating appropriate licenses with the IP owners. As another example of specifications requiring support for other specifications, SVG viewers are required to support both JPEG and PNG: http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers SVG is not a spec I would recommend using as an example of a good spec. And I haven't seen anyone writing standards like Yes, we support SVG, but not the bit which says we need to support JPEG and PNG. 3GPP has said exactly that with the video codec part of SVG. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] on codecs in a 'video' tag.
On 3/30/07, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 29 Mar 2007, Gervase Markham wrote: Dave Singer wrote: No, writing it into the HTML specification is not a commercial reason. Assuming you have commercial reasons for supporting HTML 5 (which I suspect you do, otherwise you wouldn't be here) then having Ogg specified gives you a commercial reason to support it. If that's not a commercial reason, then what would be a commercial reason? If everyone else implemented it? A _commercial_ reason would be our customers demand it. Customers in this case would be users, and users would demand it if a big video site started using Ogg Theora. You'd be surprised at the number of people coming to the Xiph community and asking for Ogg Theora support for their Mac. Fortunately there's XiphQT. Similarly for Windows - and again, fortunately there's OggCodecs. Not everyone knows what happens when they go to a video site and are unable to play the video. Your ordinary consumer will just shrug and go away. A free codec without any marketing and sales behind it will never cause the same sort of customer demand as when there's marketing. In any case... this discussion is slowly going off topic... Regards, Silvia.
[whatwg] HTMLFormElement reset method
In section 7.1 of the WA 1.0 draft [1], there is the following text: The reset() method resets the form, then fires a a formchange event on all the form controls of the form. In the case of a form seeded with initial values [2], it is not clear to me whether the intention is for the form's reset() method to reset the form to some sort of blank state or to the state immediately following the seeding of initial values. Clarity on this point would be appreciated. Thanks. [1] - http://www.whatwg.org/specs/web-forms/current-work/#form.checkvalidity [2] - http://www.whatwg.org/specs/web-forms/current-work/#seeding -- Brad Fults
