Re: [whatwg] Video
VideoLAN (http://www.videolan.org/) has developed a decoder for their low footprint media player, that decodes all major video formats and others. It's much more stable than a regular codec, because it was made to stream from the internet, being therefore prepared to receive all kinds of garbage in the stream, and still being able to decode the stream. I already had some practical experience with damaged MPEGs which crashed any media playe on my PC, while VLC behaved flawlessly. Eventually, UAs could make default use of VLC's browser plugin, or embed it directly within the browser. Henri Sivonen <[EMAIL PROTECTED]> escreveu: On Oct 31, 2006, at 07:43, Lachlan Hunt wrote: Perhaps, to go along with the Audio() interface, we could have a Video() interface as well. Maybe it would be wise to introduce a MultiMedia() interface, which is then inherited by both the Audio() and Video() interfaces and extended by each with APIs specifically for their respective media. e.g. Video() could have an API for capturing a frame and exporting it as a JPG or PNG. Defining which video format for browsers to support is out of scope of the WHATWG and HTML5. However, I do agree that there needs to be a more widely supported format so that websites don't have to offer the user a choice (commonly WMV, Quick Time and Real). If offered a choice, it should only be to pick one suitable for their bandwidth. These are not technical problems but legal ones. Browser vendors are wise to stay at an arms length from video formats due to patents. There's a suite of standards for this stuff: MPEG-4. This isn't about lack of de jure specs or technology. If there weren't patents on MPEG-4, browser vendors could integrate support for H.264 video with LC-AAC audio in an MP4 container and the problem would be solved--just like browsers include support for JPEG. However, JPEG and MPEG-4 are substantially different from the legal perspective. What browser vendors could do is move the point of plugging encumbered modules to a different place. That is, browsers could hook up to Gstreamer, QuickTime or the Windows Media framework and leave codecs and stream splitters to be plugged on the generic video framework level. But this would mean inheriting the limitations of the video framework in terms of what can be plugged. And on Windows the framework gatekeeper is hostile and on Mac OS X the framework may have technically unsatisfactory limitations. (I am not sure if the Windows Media framework is flexible enough to allow MP4 and Ogg stream splitters and corresponding streaming protocol clients to be plugged.) It would be very nice to have a widely supported, non-proprietary, patent free format on the web, which is also completely free of DRM. Agreed. I would love to see Ogg Vorbis/Theora become as successful in the audio and video market as PNG has for images, but the current problem holding it back is the lack of implementation in the major media players and browsers. ... Aside from the companies who have a stake in proprietary formats, I'm sure they would like to because they could save money on licensing fees. It isn't just the network effects of installed base (lack thereof) that are holding Theora back. Theora is not technically as advanced as H.264 or WMV9 (or even H.263 apparently). In general, a Theora-encoded video requires more CPU power for decompression than a comparable video encoded using a codec encumbered by the MPEG-LA portfolio. Also, to achieve similar subjective quality, you need more bits with Theora than with recent codecs encumbered by the MPEG-LA portfolio. According to Chris DiBona, the bandwidth issue is why Theora is not good enough for Google Video. Also, he said that Google does pay MPEG-LA, so I guess Google has figured that paying MPEG-LA costs less than the additional bandwidth required by Theora (plus the installed base issues). And about stakeholders: If you look at who have stuff in the MPEG-LA and Via Licensing portfolios and who ship handheld devices, it becomes apparent that not only does it seem that key handheld vendors have their protection sorted out but they also have an interest in the portfolios. P.S. Those who read Finnish may be interested in http://www.effi.org/sananvapaus/videotiedostomuoto.html
Re: [whatwg] How not to fix HTML
Na , Ian Hickson <[EMAIL PROTECTED]> escreveu: On Mon, 30 Oct 2006, Joao Eiras wrote: Ian Hickson <[EMAIL PROTECTED]> escreveu: > > * Make embed legal. Give it up, people: object doesn't work and never > > will. > HTML5 will make legal. Object works pretty fine. embed is duplicated functionality, not as flexible and accessible as object. Browsers will continue to suport embed, but the recomendations shouldn't. Why not? Embed doesn't provide a fallback mechanism, and mixing parameters to the plugin, and attributes can be error prone, depending on the plugin, while object makes use of param.
Re: [whatwg] How not to fix HTML
Ian Hickson <[EMAIL PROTECTED]> escreveu: * Make embed legal. Give it up, people: object doesn't work and never will. HTML5 will make legal. Object works pretty fine. embed is duplicated functionality, not as flexible and accessible as object. Browsers will continue to suport embed, but the recomendations shouldn't.
Re: [whatwg] Canvas lack of drawString method
I think mixing CSS and Canvas is a bad idea.
You could develop an application which would implement the canvas APi, and
be easily programed with ecmascript or java.
Adding this kind of feature would force the implementor to support CSS
too, at least partially.
Stefan Haustein <[EMAIL PROTECTED]> escreveu:
Hi David,
I think it is very important to be able to determine the rendered size
of the text. Otherwise, there is no reliable way to make sure things do
not overlap. Also, some kinds of applications (flash-like effects,
labels expressing weight or distance, WYSIWYG text editors) may require
variable font sizes or styles.
What do you think about
context.textStyle = "barchart"; // style by reference
context.textStyle = { // set style directly
"font-size": "8px",
"font-family": "Monaco, monospace"
}
context.drawText(x,y,string); context.getFontAscent();
context.getFontDescent();
context.getFontLeading();
context.getTextWidth(string);
Best regards,
Stefan
David Hyatt wrote:
I think a drawText method would be extremely useful.
Rather than specifying stylistic information explicitly (via a font
object), I'd use a special parenthetical pseudo-element. thus allowing
the author to specify the style as for any other element on a page
something like this...
canvas::canvas-text(barchart)
{
font-size: 8px;
font-family: Monaco, monospace;
}
and then the API would be something like:
drawText(y-coord of baseline, "barchart", myText)
and letter-spacing/word-spacing would work, small-caps would work,
text-shadow would work, etc. etc.
fitTextToPath might be an interesting API too.
dave
([EMAIL PROTECTED])
On Oct 23, 2006, at 4:07 PM, Stefan Haustein wrote:
Gervase Markham wrote:
Stefan Haustein wrote:
I think drawElement(elem) opens up a whole new can of worms:
- how would an application determine the size of the text box?
- where is the baseline position, needed for exact axis label
positioning?
- there are probably issues with dynamically calculated text values
- code with lots of cross references to elements will be difficult
to read
- it needs to be specified whether css properties are inherited from
the parent element of "elem".
- how much horizontal/vertical space is drawElement permitted to use
for rendering?
The answer to all of these things is that the browser renders all the
elements in the page as it would if the were not supported
and the alternate content were being used. It then basically
screenshots the area corresponding to the element (yes, I know this
needs careful definition) and draws that into the canvas.
I do not see how your statement answers any of my questions except
from the last one. You can specify some CSS constraints, but how do
you determine the actual rendering height of a text box with a
specific width? How do you determine the pixel position of the
baseline? The cross reference and the dynamic text issues are not
addressed at all.
Like I said, we want to leverage the browser's deep and complex
knowledge of text rendering as much as possible, and just take the
resulting pixel output as it would be shown to the user.
- the implementation in actual browsers may be more complex than it
seems because of problems with internal data structures for
rendering hints and implicitly introducing the ability to render the
same element twice.
- what happens with contained plugins, canvas elements,
self-references... all this stuff needs to be well-defined
Indeed. I know it's easy to state and there are edge cases. But we
could put limits on it like e.g. no plugins, no , and still
have something very useful for rendering text.
So I assume we agree that the element rendering proposal would still
need significant specification work and is probably much more
difficult to implement. The element rendering approach may make
working with bulk text simpler, but this case is already handled quite
fine by HTML outside the Canvas element. By asking for too much, we
may end up with nothing at all.
Andrew has provided a clear and simple proposal that can easily be
implemented without too much consideration of side effects. Putting
labels on maps, precise text positioning, starwars-like 3d scrolling
text, labels for game characters or in physics simulations, all the
stuff that could only be done in a canvas element, is trivial to
implement with the drawText() approach, but seems much more complex or
impossible with the element rendering approach.
Moreover, drawElement() would not solve the drawText problem for
non-browser environments such as Rhino.
How are we anticipating might be used in a non-browser
context?
Canvas and some other parts of the spec (e.g. connections) may make a
lot of sense for Javascript outside of the browser context. This may
be outside of the scope of WHATWG, but if we can take out some
building blocks and use them somewhere else, this is at least
Re: [whatwg] getElementsByClassName()
Na , Ian Hickson <[EMAIL PROTECTED]> escreveu: On Tue, 24 Oct 2006, Joao Eiras wrote: The question is.. is there really the need for the array ? Most bindings support variable arguments. The initial proposal used varargs, but people pointed out that that made it difficult to call the method with an arbitrary number of arguments, which is why it now takes an array. Ok then, but there could be that option for both Java's and ecmascript's bindings. Instantiating an array adds bloat to the code and inefficiency. So this would be something to keep.
Re: [whatwg] getElementsByClassName()
Na , Ian Hickson <[EMAIL PROTECTED]> escreveu: On Mon, 23 Oct 2006, Dean Edwards wrote: Personally, I prefer a comma delimited list. Passing an array seems yukky. Really? I always thought the comma-separated argument to window.open() was one of the ugliest APIs ever... Are there any problems with passing a JavaScript array to a DOM method? Does it cast to a DOMArray or something? What about other platforms? It's an array. Most languages support arrays. Why would there be a problem? The question is.. is there really the need for the array ? Most bindings support variable arguments.
Re: [whatwg] Constrains of the value propety of Controls
Value isn't readonly, and you might not have an index but a string. I'm not asking help how to code. I'd like to know what happenns in case 'VALUE' is set . Master Br <[EMAIL PROTECTED]> escreveu: João: I think that the correct approach is to define the SELECTED INDEX of the list, never to try setting the list value directly. Indeed, I think that the value property is READ-ONLY in this case... so you can NOT set Right approach: objectSelect.selectedIndex = DESIRED_INDEX; Joao Eiras escreveu: Currently, no DOM specification explicitly defines behaviour and restrictions when setting the value of the value property for elements part of forms, like select, option, and input. That's however, work that's being done at WHATWG. Yet, one single case persists: - the value property of a HMTLSelectElement is a limited domain, formed by the value of the select's child option elements value property. Is this a valid assertion ? What is expected to happen when a script tries to set the value of the value property of a select element, value which doesn't exist among it's children ? Should the value remain unchanged ? An error thrown ? thank you.
Re: [whatwg] some comments on DOM collections
Anne van Kesteren <[EMAIL PROTECTED]> escreveu: * Error handling needs to be defined for HTMLCollection.item() and HTMLCollection.namedItem(). What happens if there's no such indexth node or node with that id? This also applies to HTMLFormControlsCollection and HTMLOptionsCollection. From http://www.w3.org/TR/2001/WD-DOM-Level-2-HTML-20011025/html.html#ID-33262535 item This method retrieves a node specified by ordinal index. Nodes are numbered in tree order (depth-first traversal order). Parameters index of type unsigned long - The index of the node to be fetched. The index origin is 0. Return Value Node - The Node at the corresponding position upon success. A value of null is returned if the index is out of range. This is the best thing to do, from my multiple experiences with ecmascript.
Re: [whatwg] [WebForms2] custom form validation notifications
Matthew Paul Thomas <[EMAIL PROTECTED]> escreveu: On Oct 4, 2006, at 4:05 PM, Brad Fults wrote: On 10/3/06, Joao Eiras <[EMAIL PROTECTED]> wrote: ... If the user fills a form in an improper way the UA should alert him of the problems. Opera in the early days of its initial web forms support showed an alert box stating that the information was invalid, now it flashes the input field, and presents a message overlapped in the webpage. However it presents a very generic error message like "You must set a value!" (for required) or "foo is not in the format this page requires" (for pattern). The author may want, in the case of an error, to present its custom error message to the end user. This could be achieved by declaring new custom attribute for the several controls, which could hold the message. The UA could then either pop up that message to the user or embed it in the page (like Opera does currently). The attribute could be named like requirederr, patternerr, or use some other sort of naming convention to easily associate the constraining property with the message attribute. As UAs become more sophisticated, they can analyze the pattern attribute and present more context-sensitive error messages than any such attribute could. For example: * "410 is too much; this number must be 300 or less." * "178 is too small; this number must be 200 or more." * "This field must start with a letter." UAs can also localize these error messages much more extensively than any Web site could (which will be even more of a benefit when the Web site is not in your preferred language). Of course. Such features are very useful, although such behaviours are user-agent defined. But that's not the point: my original message is related to customizablility. Is the use of the title attribute inappropriate for this case? ... It has the same lack of context.
Re: [whatwg] [WebForms2] custom form validation notifications
Matthew Paul Thomas <[EMAIL PROTECTED]> escreveu: On Oct 4, 2006, at 4:05 PM, Brad Fults wrote: On 10/3/06, Joao Eiras <[EMAIL PROTECTED]> wrote: ... If the user fills a form in an improper way the UA should alert him of the problems. Opera in the early days of its initial web forms support showed an alert box stating that the information was invalid, now it flashes the input field, and presents a message overlapped in the webpage. However it presents a very generic error message like "You must set a value!" (for required) or "foo is not in the format this page requires" (for pattern). The author may want, in the case of an error, to present its custom error message to the end user. This could be achieved by declaring new custom attribute for the several controls, which could hold the message. The UA could then either pop up that message to the user or embed it in the page (like Opera does currently). The attribute could be named like requirederr, patternerr, or use some other sort of naming convention to easily associate the constraining property with the message attribute. As UAs become more sophisticated, they can analyze the pattern attribute and present more context-sensitive error messages than any such attribute could. For example: * "410 is too much; this number must be 300 or less." * "178 is too small; this number must be 200 or more." * "This field must start with a letter." UAs can also localize these error messages much more extensively than any Web site could (which will be even more of a benefit when the Web site is not in your preferred language). Of course. Such features are very useful, although such behaviours are user-agent defined. But that's not the point: my original message is related to customizablility. Is the use of the title attribute inappropriate for this case? ... It has the same lack of context.
Re: [whatwg] [WebForms2] custom form validation notifications without scripting
Na , Brad Fults <[EMAIL PROTECTED]> escreveu: On 10/3/06, Joao Eiras <[EMAIL PROTECTED]> wrote: Although WebForm2 provides automatic validation of form content from the UA side, the specification has a few gaps related to customizablility of notifications, by web authors, without scripting enabled. If the user fills a form in an improper way the UA should alert him of the problems. Opera in the early days of its initial web forms support showed an alert box stating that the information was invalid, now it flashes the input field, and presents a message overlapped in the webpage. However it presents a very generic error message like "You must set a value!" (for required) or "foo is not in the format this page requires" (for pattern). The author may want, in the case of an error, to present its custom error message to the end user. This could be achieved by declaring new custom attribute for the several controls, which could hold the message. The UA could then either pop up that message to the user or embed it in the page (like Opera does currently). The attribute could be named like requirederr, patternerr, or use some other sort of naming convention to easily associate the constraining property with the message attribute. Is the use of the title attribute inappropriate for this case? I believe title is used for a berief description, not for error messages, besides a control may not validate for more than one reason.
[whatwg] [WebForms2] custom form validation notifications without scripting
Although WebForm2 provides automatic validation of form content from the
UA side, the specification has a few gaps related to customizablility of
notifications, by web authors, without scripting enabled.
If the user fills a form in an improper way the UA should alert him of the
problems. Opera in the early days of its initial web forms support showed
an alert box stating that the information was invalid, now it flashes the
input field, and presents a message overlapped in the webpage.
However it presents a very generic error message like "You must set a
value!" (for required) or "foo is not in the format this page requires"
(for pattern).
The author may want, in the case of an error, to present its custom error
message to the end user.
This could be achieved by declaring new custom attribute for the several
controls, which could hold the message. The UA could then either pop up
that message to the user or embed it in the page (like Opera does
currently).
The attribute could be named like requirederr, patternerr, or use some
other sort of naming convention to easily associate the constraining
property with the message attribute.
If the UA has scripting disabled, trying to prevent the default action for
an invalid event won't work. Too overcome this problem, there could be a
new attribute which could be called 'notifyoninvalid="true|false"' with a
default value of true, for each control, or for the entire form. If the
value is false, then the UA wouldn't notify the user in case of
invalidity. This could then be delegated to some CSS using :invalid;
Now, to ease the authors work, there could be another css pseudo-classes,
to compliment :invalid, which is :valid
*:valid{border:thin solid green;}
This way it's more easy to provide custom notifications, instead of
default ones, with no scripting.
Goodbye.
Re: [whatwg] [WF2]
Well, the option element could be extended with a new attribute 'invalid'
which hold prevent that option to be selected.
Robert <[EMAIL PROTECTED]> escreveu:
On Mon, 02 Oct 2006 16:35:32 +0200, Simon Pieters <[EMAIL PROTECTED]>
wrote:
I've seen a case where a is used and the user is required to
change its value, as in:
Select one:
Foo
Bar
Now this can be done with radio buttons instead, but why can't the
above be supported? That is, make required apply to s and if
the value is empty then required is not satisfied. (Same for multiple>.)
Submitting an empty value may be wanted, and since a select by
definition is a list of predefined valid values, it would make little
sense to prevent the user from selecting some of them. However, I agree
with the use case of the invalid starter value so users must consciously
select a value they wanted instead of the default one.
The following script will do exactly what you wanted, although Opera
doesn't seem to use the custom error message for some reason. I'm not
sure if that's my fault or Opera's due to my lack of experience with
WF2, but it does prevent form submissions just fine as long as there are
invalid selects.
The script works in Opera 9.02.
http://www.w3.org/1999/xhtml';},4,null);
var elem=null;
while(elem = res.iterateNext()){
if(!elem)break;
checkSelect({'target':elem}); // do initial check
elem.addEventListener('change',checkSelect,false);
}
]]>
--
Robert Græsdal
[whatwg] MediaModeAbstractView and changing of media dynamically
For me, the w3c DOM 2 stylesheets spec always had the gap, which MediaModeAbstractView fixes: a variable which holds the current media how the page is being rendered. But there's another small gap. Some UAs (Opera for desktop only to my knowledge) can change the current media by displaying a webpage as fullscreen (projection) or enabling small screen rendering (handheld). I assume future versions will allow Opera to trigger tv mode, for development sake. Also any other browsers can change from normal rendering (screen) to print preview (print). The only way for a script to keep track of this variable value, is to set an interval, polling the variable. I don't consider refreshing the page as valid workaround. So, I suggest the creation of the 'media-change' event, which will fire when the UA changes media, having the document as target. The event object could be an instance of a UIEvent, and have 2 extra properties: newMediaMode, and oldMediaMode.
