Re: [whatwg] Possible alternative to specifying a codec for the video tag
Dnia 23-12-2007, N o godzinie 13:08 +, David Gerard pisze: On 23/12/2007, Robert (Jamie) Munro [EMAIL PROTECTED] wrote: How could we do that? The codec is usually a relatively small download download compared to the video itself. If we could suggest a way for codecs to be provided alongside the videos by the content providers, this /may/ be a way forward. Hypothetically, you could do video by adding better binary file handling to Javascript, and painting on the canvas, but good performance is unlikely. Arbitrary executable downloads didn't work out well with ActiveX, and Download codec to view this! is already a vector for malware. That would not be an arbitrary download; it would be a download of _the_ codec. The executable code must not be enclosed in the content envelope (unless the envelope is generated on the fly by the server depending on the user agent; I think it would be a cumbersome thing to do). Arbitrary active extensions can request services from the operating system; the code to be executed should not be allowed to. It could be allowed to request services from the browser only; if that is set up correctly, the decoder will be as safe as the browser is, even if it is a piece of broken malware. Thus we would need the browser to be a direct show* engine provider for the decoder and the decoder would be allowed to access its own memory only and call its own functions and the functions explicitly provided by the browser. Is this feasible? Who would be in charge of wrapping the decoder for all the various browser implementations out there? Because each of them can provide a different interface to the decoder. The publishers? And what if some browser vendor decides to issue an incompatible update? I doubt the publishers are able to follow the technology that closely; they probably have something else to do. The decoder engine vendors? They should be able to this but their consent, or at least their opinion, is required in this case. And, last but not least: can we expect the opposing browser vendors to offer the direct show engine and allow the decoder to run without much user intervention? Because if not, this solution would be very weak. What do you think? Chris *(Note: DirectShow, IIRC, is a video-related trademark owned by Microsoft. I used it here because of lack of a better expression.)
Re: [whatwg] Possible alternative to specifying a codec for the video tag
On 24/12/2007, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: Dnia 23-12-2007, N o godzinie 13:08 +, David Gerard pisze: On 23/12/2007, Robert (Jamie) Munro [EMAIL PROTECTED] wrote: How could we do that? The codec is usually a relatively small download download compared to the video itself. If we could suggest a way for Arbitrary executable downloads didn't work out well with ActiveX, and Download codec to view this! is already a vector for malware. That would not be an arbitrary download; it would be a download of _the_ codec. The executable code must not be enclosed in the content envelope (unless the envelope is generated on the fly by the server depending on the user agent; I think it would be a cumbersome thing to do). Arbitrary active extensions can request services from the operating system; the code to be executed should not be allowed to. It could be allowed to request services from the browser only; if that is set up correctly, the decoder will be as safe as the browser is, even if it is a piece of broken malware. Thus we would need the browser to be a direct show* engine provider for the decoder and the decoder would be allowed to access its own memory only and call its own functions and the functions explicitly provided by the browser. Is this feasible? It still sounds to me a bit like a layer violation ... the content in question is a bit active. Mind you, HTML these days is generally riddled with (or only a delivery mechanism for, e.g. in interactive television) JavaScript. And codecs are a bit virtual-machine-like anyway (with playback engines needing sandboxing to protect against codecs that are unsecure against malicious files). And, last but not least: can we expect the opposing browser vendors to offer the direct show engine and allow the decoder to run without much user intervention? Because if not, this solution would be very weak. What do you think? It strikes me as more trouble than it would be simply to remember that in claiming Ogg was proprietary, Nokia told a lie big enough to crack and break the assumption of good faith; and if Apple could really live with SHOULD in the spec, put back the baseline recommendation of Ogg Theora and Ogg Vorbis. - d.
Re: [whatwg] must only ambiguity
Dnia 21-12-2007, Pt o godzinie 17:28 +, Philip Taylor pisze:
Documents and document fragments / Structure says Authors must only
use elements in the HTML namespace in the contexts where they are
allowed, as defined for each element.
That phrase is unclear. It could be interpreted as:
Authors must { only use elements in the HTML namespace } in { the
contexts where [elements in the HTML namespace] are allowed }, i.e.
contexts expecting HTML namespaced elements mustn't contain foreign
content.
Authors must { [...] use elements in the HTML namespace } [only] { in
the contexts where they are allowed }, i.e. HTML elements must not be
used where they aren't allowed.
Authors must only { use elements in the HTML namespace in the
contexts where they are allowed }, i.e. pretty much every imaginable
action in the entire world is disallowed, except for using elements
where allowed.
A suggested replacement: Authors must not use elements in the HTML
namespace except where allowed by the context defined for the
element.
My rewording for competition:
Authors may use elements in the HTML namespace
in the contexts where they are explicitly allowed and nowhere else.
Similarly, Authors must only put elements inside an element if that
element allows them to be there according to its content model should
be fixed to say something like Authors must not put elements inside
an element unless that element allows them to be there according to
its content model.
My rewording for competition:
Authors may put elements inside an element only if that element...
(because only if is a common and well understood expression.)
Chris
Re: [whatwg] must only ambiguity
On Monday 2007-12-24 19:07 +0100, Krzysztof Żelechowski wrote: My rewording for competition: Authors may use elements in the HTML namespace in the contexts where they are explicitly allowed and nowhere else. My rewording for competition: Authors may put elements inside an element only if that element... (because only if is a common and well understood expression.) These won't work because they make the statement a much weaker requirement per RFC 2119: http://www.ietf.org/rfc/rfc2119.txt Changing from a MUST or MUST NOT to a MAY is a substantive change, not a rewording. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
