Re: [whatwg] element feedback

[Shadow2531]

On 3/29/07, Laurens Holst <[EMAIL PROTECTED]> wrote:

The URL parameter (as also seen in e.g. Quicktime and Flash) is imho a
dirty hack to work around implementations not providing plugins with a
streaming file reader object. At least, that is the only explanation I
can come up with. There is a DATA attribute on the object, and that
should be sufficient.


There are a few problems with data for OBJECT and src for EMBED.

1. The plugin doesn't always support those params for a file resource
and browsers have to hack in support on a per-plugin basis to make src
/ data work (if they choose to).

The java plug-in, tcl plugin, wmp plugin, neptune plugin, videolan
plugin, tcl plugin and the Real plugin all don't support a data param
by theirselves.

2. They cause the browser to automatically download the resource.


A plugin should support 3 different params for specifying a source file.

'data' to cause the browser to automatically download the resource via OBJECT:


'src' to cause the browser to automatically download the resource via EMBED:


'another_param' to prevent the browser from automatically downloading
the resource if a autoplay (for example) param is set to false:

   
   

object.play() starts the downloading.


embed.play() starts the downloading

(The effect of another_param could be simulated by just writing out
the whole object with JS when ready, but ...)

Anyway, with a VIDEO element, that stuff wouldn't be a problem as it
can be dealt with specifically as opposed to OBJECT where you have to
worry about all the existing behaviors.

--
burnout426

Re: [whatwg] element feedback

[Shadow2531]

On 3/29/07, Henri Sivonen <[EMAIL PROTECTED]> wrote:

On Mar 29, 2007, at 08:04, Boris Zbarsky wrote:

> Laurens Holst wrote:
>> So, what do you think would be needed to fix this situation.
>
> In my dream world, IE would support dispatch by MIME type and
> authors who don't care about targeting a specific plug-in binary
> could just stop using the classid mess.

I've asked about this before but I still don't understand it: Why
doesn't Gecko completely ignore the classid? (IIRC, Opera on Mac and
Mac IE 5 ignore the classid and dispatch on MIME.)


Here's just one  example of what Boris is referring to with different
implementations.


   
   
   


That classid invokes the Windows Media 7+ ActiveX control.  If FF
ignores the classid and uses type and data, FF will be using the
Netscape WMP 6.4 plug-in.

For the 6.4 plugin (which is older than dirt, but all there is
netscape-wise because MS has abandoned it (and even broken
compatibility with it in WMP11)), boolean values coming from params
have to be 1 or 0. True or false are not understood. In this case, the
video would still autostart.  Also for the 6.4 plug-in, volume is
different. It doesn't want a percentage, it wants -1 to 0
(logarithmic scale).  The 6.4 plugin also doesn't understand URL, it
wants a filename param. There are also other params that only exist in
one of the implementations.

Now, for that to work, FF would have to convert false to 0 before
passing to the 6.4 plugin. It would have to convert 50% to ~ -612
before passing to the plug-in. It would have to convert URL to a
filename param before passing to the plugin.

Since the plugin doesn't understand a data param, FF already has to
map data to filename, so, in this case, that part at least is not a
problem, but the rest of the compatibilities still are.

Also, the codebase attribute in this case (if it was present) would
have to be checked by FF first to make sure it wasn't a path to a .cab
file (for IE) before it was used to resolve a path for file.wmv.

Further, FF would have to do all these type of things on a per-plugin
basis for every plug-in where the ActiveX version exposed a different
api compared to the netscape version.

Even more, the JS methods exposed on the object between the 2 APIs are
very different.

However, if the wmp classid of
"clsid:22D6F312-B0F6-11D0-94AB-0080C74C7E95" was used, that would
invoke the WMP 6.4 ActiveX control where the author would be using
6.4-compatible params where param converting would not be needed. So,
there's have to be a condition where converting would not happen.

So, it's possible for FF to ignore classid and have things work fine,
but I assume there'd be a lot of bloat going on behind the seen to
make sure that it happens correctly.

If other browsers ignore classid and things work out, there's most
likely a bunch of converting going on to make it work, but it will
still probably break in advanced situations.

Now, if you want nested objects, IE7 will handle that. If you're
worried about IE6, we can use downlevel-hidden IE conditional comments
for that.

--
burnout426

[whatwg] EMBED should not require src if type is specified.

[Shadow2531]

As mentioned offtopic in
<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-November/007936.html>,
just like OBJECT, for EMBED, the src attribute is not always needed
and sometimes it must not be present.

The best example for not requiring src is the tcl plug-in.
<http://shadow2531.com/opera/testcases/plugins/tcl/001.html>
<http://shadow2531.com/opera/testcases/plugins/tcl/001-a.html>

Also, Java can be loaded via the embed element where src is not needed.
<http://shadow2531.com/opera/testcases/plugins/java/007.html>

There are other cases with the Windows Media plug-in or with the
RealPlayer plug-in where just loading the plug-in with the type
attribute and doing scripting on the object is desirable.

There's also the neptune plug-in. For example: . In this case, it wants a
param-location param and not a src param.


--
burnout426

Re: [whatwg]

[Shadow2531]

On 3/23/07, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

On Fri, 23 Mar 2007 19:07:05 +0100, Shadow2531 <[EMAIL PROTECTED]>
wrote:
> In this case, the browser shouldn't strip and normalizes the newlines
> from the value attribute before passing to the plugin. (FF and IE
> handle this nicely. They may do this only for the tcl plugin though.).

Per the parsing algorithm they should never be normalized in attributes.
I'm not sure why you're suggesting they should.


Sorry. I must have missed that the handling from
<http://www.w3.org/TR/html401/types.html#type-cdata> wasn't included
in the attribute value state and was assuming that FF and IE were
making an exception from those white-space rules (Opera follows them
for params) and not normalizing the newlines in the param's value
attribute for the tcl plugin's sake.  With that in mind, I was
concerned about the difficulty of making an exception in the
normalization for a param in OBJECT, but not a param in a media
element.

Since that's not the case, carry on. :)

--
burnout426

Re: [whatwg]

[Shadow2531]

On 3/23/07, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

I don't really like this element. The name is confusing especially with an
attribute named src="". It also introduces yet another void element, can't
we just reuse ? The value="" attribute of  would point to a
resource and the type="" attribute (which has been dropped) would be added
back. I suppose it might be considered overloading, but in a way we're
just defining how the processing model of a plugin could also work...


With OBJECT, the TCL plugin  has a
script param where you pass an inline tcl script like this (you may
remember this):



In this case, the browser shouldn't strip and normalizes the newlines
from the value attribute before passing to the plugin. (FF and IE
handle this nicely. They may do this only for the tcl plugin though.).

Now, if a param element was used inside a media element, that
exception for the param's value attribute would not be needed and
normalize whitespace handling would be used.

Is there any problem with making the param value attribute inside a
media element have a different whitespace normalization than it would
if inside OBJECT?

If there is a problem doing that, then perhaps having  would
avoid that. If there is no problem, then  seems like it'd be
just fine instead of .

--
burnout426

Re: [whatwg] Full screen for the element

[Shadow2531]

On 3/22/07, Nicholas Shanks <[EMAIL PROTECTED]> wrote:

To me full screen mode for video would not alter the browser window
size, instead it would cover the screen in a new window and draw just
the video into that. The browser window would be left untouched below
(though the video may no longer be rendering into it).


I kind of figured it'd be like that also.  When you switch to full
screen, the window would stay the same size.  The embedded video would
switch off and the video overlay would appear and cover the whole
screen.

--
burnout426

Re: [whatwg] fallback behaviour (was: Re: element feedback)

[Shadow2531]

On 3/20/07, Robert Brodrecht <[EMAIL PROTECTED]> wrote:


Simon Pieters said:
> Oh. I thought  fallback would work pretty much like 
> fallback, but I see that's not the case. When I think about it it makes
>  sense;  is pretty much like , it never falls back in UAs
>   that support it.

Oh, damn it.  I thought it'd work like , too.  I'm not sure I like
the only-fallback-if-no-support idea.  I'm getting the feeling that there
won't be one common video format among the browsers.  I think not having
fallback to nested video elements to get at other formats would ultimately
be a bad thing.


It is different than expected, but I can now see  why video would want
to avoid these things.

If you load an applet, with the object element, it'll never fallback
(even if the class file can't be found) unless java is turned off or
not supported. If you load 

Re: [whatwg] element feedback

[Shadow2531]

On 3/20/07, Ian Hickson <[EMAIL PROTECTED]> wrote:

On Wed, 21 Mar 2007, Lachlan Hunt wrote:
> >
> > I only included togglePause() because Flash supports it and some
> > people asked for it; I'm not convinced we should keep it.
>
> I'm in favour of dropping it.  It's an unnecessary API for browsers to
> support.  It adds nothing that can't be done with play()/pause() and an
> if statement.
>
> if (video.state == HTMLVideoElement.PAUSED) {
> video.play();
> } else {
> video.pause();
> }

On Tue, 20 Mar 2007, Jeff Cutsinger wrote:
>
> +1.

I've commented it out for now. Let's see how many people complain.


No objections. Also +1.


On Tue, 20 Mar 2007, Shadow2531 wrote:
>
> So, if one used  , there'd be no way to make the video display at 200 x
> 200 because it would always scale?

Currently, correct.


Thanks.


> If so, if one wanted to simulate the look I'm describing, would one have
> to do the following for example?
>
> 
>
> 
>
> (Just want to be sure.)

Yeah, you could do that.


Thanks


> I'm thinking more along the lines of a local HTML page that embeds a
> local video (one of your favorites for example) where when you load the
> page (via a bookmark or a panel for example), it automatically starts
> and is set to loop (because you authored it that way).

Well for local content we don't need to worry about interoperability
(since the user makes it for himself on his user agent), so user agents
are free to add vendor extensions to do this, or the user could use JS, or
the user could do something that doesn't involve HTML at all, that's not
really our problem.


Point taken.


> So, this is all that is needed to do autostart?
>
> window.onload = function() {
>document.getElementsByTagName("video")[0].play();
> };

That will do it, yes, assuming the user agent doesn't block it (the spec
allows that, under use control).


Thanks


> > > However, if JS is needed for the video element to function at all,
> > > then the video element needs to fall back if JS is turned off.
> >
> > Interesting point.
>
> Yes, since JS is required, if JS is off, the browser should display the
> alternate content.
>
> > You can do this with JS, of course (and that's the preferred way; hide
> > the fallback when you have JS).
>
> Are you saying that with JS on, the fallback content will be displayed
> in addition to the video and you have to use JS to hide the fallback
> content like the following?
>
> window.onload = function() {
>var x = document.getElementsByTagName("video")[0];
>x.play();
>x.innerHTML = "";
> };

No, I meant something like:

   
 You need JavaScript turned on to do video.
   
   
 // clear the fallback
 var v = document.getElementById('video');
 while (v.hasChildNodes) v.removeChild(v.firstChild);

 // get the data to play
 var src = 'video.ogg';

 // create the UI
 default xml namespace = "<a  rel="nofollow" href="http://www.w3.org/1999/xhtml"">http://www.w3.org/1999/xhtml"</a>;;
 var ui = <div>
<p><video src={src}></video></p>
<p>
 <input type="button" value="Play" onclick="vPlay()"/>
 <input type="button" value="Pause" onclick="vPause()"/>
</p>
  </div>;
 var video = ui..video.domNode();
 function vPlay() { video.play() }
 function vPause() { video.pause() }
 v.appendChild(ui.domNode());

 // start playback
 video.play();
   

Or, probably better:

   
 You need JavaScript turned on to do video.
   
   
 
 
   
   
 
   
   
 // clear the fallback
 var f = document.getElementById('no-js-warning');
 f.parentNode.removeChild(f);

 // UI functions
 function vPlay() { video.play() }
 function vPause() { video.pause() }

 // start playback
 video.play();
   


Thanks. I'm all set on this now.

--
burnout426

Re: [whatwg] element feedback

[Shadow2531]

On 3/20/07, Christoph Päper <[EMAIL PROTECTED]> wrote:

Maybe it is a stupid idea, but is something like the following
imaginable to make a XHTML5 browser display inline video with a basic
UI without the need for scripting?

   
 
 
   


I thought about this myself.

My thought looked like this:





However, my thought would abuse a possible video: protocol and make
input or button or forms in general even more complicated.

I don't think implementors would be interested in hacking up forms
this way, but I could be wrong.

--
burnout426

Re: [whatwg] element feedback

[Shadow2531]

On 3/20/07, Simon Pieters <[EMAIL PROTECTED]> wrote:

On Tue, 20 Mar 2007 16:18:16 +0100, Shadow2531 <[EMAIL PROTECTED]>
wrote:

>> > However, if JS is needed for the video element to function at all,
>> then
>> > the video element needs to fall back if JS is turned off.
>>
>> Interesting point.
>
> Yes, since JS is required, if JS is off, the browser should display
> the alternate content.

Disagreed. You can still start the video with the context menu or from the
separate window mode or full screen, or whatever (non-inline) UI the
browser provides. Also, as soon as browsers have implemented what is
currently specced, it is expected that declarative features for a native
UI will be added, so then it should *not* fall back with JS off. Making it
fall back for v1 but not for v2 would just cause interoperability problems.

You would have to script the fallback, as everything else with v1. ;-)


:) Understood.


>> You can do this with JS, of course (and that's the
>> preferred way; hide the fallback when you have JS).
>
> Are you saying that with JS on, the fallback content will be displayed
> in addition to the video and you have to use JS to hide the fallback
> content like the following?
>
> window.onload = function() {
> var x = document.getElementsByTagName("video")[0];
> x.play();
> x.innerHTML = "";
> };

That wouldn't help, as without JS you wouldn't access the fallback
content. You could do this:

fallback

 var video = document.createElement("video");
 video.src = "foo.ogg";
 var fallback = document.getElementById("videofallback");
 var parent = fallback.parentNode;
 var pos = fallback.nextSibling;
 video.appendChild(fallback);
 parent.insertBefore(video, pos);


BTW, this would be a lot simpler to do if the src="" attribute was made
optional:

fallback

 document.getElementsByTagName("video")[0].src = "foo.ogg";


I think this should be allowed. Without the src attribute, the video
element could represent a placeholder where a video might have been
relevant (e.g. if scripting was enabled).


I see what you're saying. If the video object is still going to start
up without JS on, then you have to omit src or just do src="" so it
falls back. Then, if JS is on, you can set the file so the alternate
content hides and the video object initializes.

Or, just create the element with JS and add it where you want.

--
burnout426

Re: [whatwg] element feedback

[Shadow2531]

On 3/20/07, Ian Hickson <[EMAIL PROTECTED]> wrote:

On Sat, 17 Mar 2007, Shadow2531 wrote:
>
> "Video content must be rendered inside the element's playback area such
> that the video content is shown centered in the playback area at the
> largest possible size that fits completely within it, with the video
> content's aspect ratio being preserved. Thus, if the aspect ratio of the
> playback area does not match the aspect ratio of the video, the video
> will be shown letterboxed."
>
> So, that also means that scaletofit in my examples is implied by that?

Yes.


Thanks.

So, if one used  , there'd be no way to make the video display at 200
x 200 because it would always scale?

If so, if one wanted to simulate the look I'm describing, would one
have to do the following for example?


   


(Just want to be sure.)


On Fri, 16 Mar 2007, Shadow2531 wrote:
>
> A video might be split into separate files (chapters). A playlist is
> needed to provide consecutive playback without user interaction and to
> provide view of your choices. If you've ever watched episodes in parts
> on youtube, you might see why this is important.

Does YouTube support this? I thought YouTube didn't support this, which
would suggest it's not a high priority...


For youtube, if you play a show that's split up into parts, after the
first part is finished, the flash will *sometimes* display a link to
the next part that you can click on. However, because it's not
automatic, it's not as friendly (depending on the desire of the user).
But, when the next part is not provided at all, it's really
unfriendly.

So, you are correct. Youtube does not do playlists to the extent I was
referring.

Given the low priority for them and the note about JS being required,
a JS simulation of playlists will do.


However, what if JS is turned off and you want to do playlists?


If JS is turned off, applications won't work. :-) Just like when you turn
JS off and try to use Google Calendar, or turn off Flash and try to use
YouTube. In v2 we can add UI features to handle this, though, such as:


True. Without a default UI and or support for params that provide
initial state, with JS off, the video won't do anything.


> > > .loop, .startpos
> > > loop = false | true
> > > autostart = true | false
> > > startpos = 0 | specified pos
> >
> > Could you elaborate on the use cases for these?
>
> 
>
> 

If the data has to be gotten from a cookie, wouldn't a JS seek() not be
better? You'll need JS to save the position anyway.


This is another case where I assumed the video element would be usable
without JS. Anyway, the cookie value written out by a php script was
just one example. The saved position could be gotten other ways.


> 
>
> 

Wouldn't the decision of whether to loop or not be a user decision? UAs
can provide a loop option as a checkable item on a context menu. I'd hate
to go to a site and have a video keep looping.


I'm thinking more along the lines of a local HTML page that embeds a
local video (one of your favorites for example) where when you load
the page (via a bookmark or a panel for example), it automatically
starts and is set to loop (because you authored it that way).

This is also another use case for playlists. One might create a local
Opera video player panel,  which like winamp, foobar, vlc etc., would
support playlists. (Many have already used OBJECT and plugins for
that.)

In the cases where you just want to play the video, it seems odd to
require JS to do it (not saying it's difficult). However, one can get
used to that. When Audio() was added, JS being a requirement was a
given because there was no element to go along with it.


> Page where a user is expecting a video to play.
> 
>
> 

We got a bunch of feedback from people saying "never autoplay!". :-)
Again, the spec allows users to control this now.


Because it's abused by many. Not allowing it would probably be a good deterrent.

So, this is all that is needed to do autostart?

window.onload = function() {
   document.getElementsByTagName("video")[0].play();
};


> However, if JS is needed for the video element to function at all, then
> the video element needs to fall back if JS is turned off.

Interesting point.


Yes, since JS is required, if JS is off, the browser should display
the alternate content.


You can do this with JS, of course (and that's the
preferred way; hide the fallback when you have JS).


Are you saying that with JS on, the fallback content will be displayed
in addition to the video and you have to use JS to hide the fallback
content like the following?

window.onload = function() {
   var x = document.getElementsByTagName("video")[0];
   x.play();
   x.innerHTML = "&

Re: [whatwg] Video proposals

[Shadow2531]

On 3/17/07, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

On Sat, 17 Mar 2007 11:56:53 +0100, Shadow2531 <[EMAIL PROTECTED]>
wrote:
> For example, every video page on a site might have a 400 x 400 video
> element (to fit with the layout for example), but the video that plays
> in it will range in size and aspect ratio.
>
> A way to solve that so the layout of the page is not disrupted would
> be to have the video element represent the video screen area where the
> video itself can be scaled and centered inside it by the browser.
>
> For example, if the 400 x 400 video element plays a 640 x 480 video
> and keepaspect is set, the video would show centered inside the screen
> area at 400 x 300. If keepaspect is not set, the video would show at
> 400 x 400.

That's how  is defined now. Except that "keepaspect" is the default
behavior and there's no way to switch. Perhaps people should reread the
draft?


"Video content must be rendered inside the element's playback area
such that the video content is shown centered in the playback area at
the largest possible size that fits completely within it, with the
video content's aspect ratio being preserved. Thus, if the aspect
ratio of the playback area does not match the aspect ratio of the
video, the video will be shown letterboxed."

So, that also means that scaletofit in my examples is implied by that?

--
burnout426

Re: [whatwg] Video proposals

[Shadow2531]

On 3/16/07, Dean Edridge <[EMAIL PROTECTED]> wrote:

I think the idea of having an attribute for the aspect ratio of a video
is a great idea, especially given the fact that web sites today should
be as fluid / liquid as possible since there is a need to cater for a
range of different screen sizes.
So this gets my vote FWIW.


Just some thoughts...

I think some video sites might want to use a video element template of
a certain size.

For example, every video page on a site might have a 400 x 400 video
element (to fit with the layout for example), but the video that plays
in it will range in size and aspect ratio.

A way to solve that so the layout of the page is not disrupted would
be to have the video element represent the video screen area where the
video itself can be scaled and centered inside it by the browser.

For example, if the 400 x 400 video element plays a 640 x 480 video
and keepaspect is set, the video would show centered inside the screen
area at 400 x 300. If keepaspect is not set, the video would show at
400 x 400.

If the video was 300 x 120, it'd show at it's original size whether
keepaspect was set or not, unless scaletofit was set. If scaletofit
was set, then keepaspect would cause the video to show at 400 x 160.
If keepaspect wasn't set and scaletofit was, the video would show at
400 x 400.

Examples:

Video element is 400 x 400, but video shows at 400 x 300 inside it.


Video element is 400 x 400 and video shows at 400 x 400 inside it.


Video element is 400 x 400 and video shows at 300 x 120 inside it.


Video element is 400 x 400 and video shows at 300 x 120 inside it.


Video element is 400 x 400 and video shows at 400 x 400 inside it.


Video element is 400 x 400 and video shows at 400 x 160 inside it.


(scaletofit is implied when the video is larger than the video element)

You might be able to simulate all of that by putting the video element
in another element and playing with css, but that probably wouldn't be
as friendly.

--
burnout426

Re: [whatwg] Video proposals

[Shadow2531]

On 3/15/07, Ian Hickson <[EMAIL PROTECTED]> wrote:

ON PLAYLISTS

On Mon, 30 Oct 2006, Shadow2531 wrote:
>
> The handler should also support some type of playlist like
> <http://www.xspf.org/>.

On Mon, 30 Oct 2006, Charles Iliya Krempeaux wrote:
>
> #3: Playlists.  (A single video file just won't cut it.)

These were the only requests for playlists. Could you elaborate on the use
cases for playlists? What are the needs for playlists?


A video might be split into separate files (chapters). A playlist is
needed to provide consecutive playback without user interaction and to
provide view of your choices. If you've ever watched episodes in parts
on youtube, you might see why this is important.

One could use the events and states to determine when a video is done
playing. Then, the src attribute could be changed to the next video.
The list of videos could be gotten from a JS array or by parsing an
xml playlist via self-written code or some playlist parsing JS
library.

However, what if JS is turned off and you want to do playlists?



The video element itself would need to handle the playlist. (Unless
you set up links to video pages that where targeted at an iframe. Even
then, user action would be required if consecutive playback was
desired.)


ON FEATURES
On Thu, 1 Mar 2007, Shadow2531 wrote:
>
> [long list of desired features]

I took your suggestions into account when desiging the API. I got feedback
from a number of people (including some off-list from people who didn't
want to express their interest publicly), some of which was contradictory,
so the proposed API doesn't have everything you asked for. Let me know if
there's anything that you think is missing that you really wanted.


Understood. Thanks.


> .loop, .startpos
> loop = false | true
> autostart = true | false
> startpos = 0 | specified pos

Could you elaborate on the use cases for these?



   



   


Page where a user is expecting a video to play.

   


Index page for example where a video starting up might not be expected.

   
   This is my index page

(From the list and the spec, it looks like the video will never play
on its own. It looks like you have to invoke play() with js or nothing
will ever happen.)

Again though, autostart, loop and startpos could be simulated with the
events and states provided.

However, what if JS is turned off?

You need params to provide initial state. JS should only be needed for
controlling/interface stuff. If you just want to have a video load and
play till the end (and loop possibly), that shouldn't require JS.

However, if JS is needed for the video element to function at all,
then the video element needs to fall back if JS is turned off.


On Thu, 1 Mar 2007, Shadow2531 wrote:
>
> I think it'd be cool if the video element *just* supported theora.

Supporting only one encoding is not going to fly: you can't stop browser
vendors from adding features; and you want to allow the standard to evolve
over time.


Understood. The SHOULD for theora is good enough.

--
burnout426

Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

[Shadow2531]

On 3/13/07, Asbjørn Ulsberg <[EMAIL PROTECTED]> wrote:

On Sat, 10 Mar 2007 21:51:14 +0100, Shadow2531 <[EMAIL PROTECTED]>
wrote:
> I guess at the least, it shows the desperate need to do something about
> IE.

I actually think the problem lies within Microsoft itself. I recommend
reading the following very entertaining articles from Joel Spolsky and
Moishe Lettvin, respectively, about the Windows Vista shut down menu:

<http://www.joelonsoftware.com/items/2006/11/21.html>
<http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html>

I'm sure things are better in the IE camp, but if the development process
of the shut down menu of Windows Vista is any indication of how it is to
be a developer in Microsoft, then it's not really that surprising that
their products end up like they do. Including Internet Explorer.


Very interesting. Thanks

--
burnout426

Re: [whatwg] Fallback behavior

[Shadow2531]

On 3/12/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:


fallback

alert('y');




I asked about this a while ago. Here's the old discussion:




--
burnout426

Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

[Shadow2531]

On 3/10/07, Mihai Sucan <[EMAIL PROTECTED]> wrote:

Le Sat, 10 Mar 2007 22:21:11 +0200, Shadow2531 <[EMAIL PROTECTED]>
> It seems that even in standards mode, people expect some quirky
> behavior and MS wants to retain the quirkyness even in standards mode.
> If they continue to fix standards mode, they'll break way too many
> sites.

Precisely! That's what I said: the standards mode in IE is rather quirky.
However, I do *not* buy it: I don't believe they'll magically come up with
IE.next having a "strict standards mode" which is up-to-par with the
standards mode in, say, Opera. Even if they do, don't think the standards
mode in Opera/Gecko/whatever is perfect either. They all have quirks. But
... because we are talking about IE, we will again end up having sites
relying on the "strict standards mode", and again Microsoft would break
way too many sites if they change the rendering in this new mode. It's an
endless loop. (see one of my previous replies to this thread)

> That's what I got out of the video.

That's correct. I did understand relatively the same.


You make a good point. It could very well be an endless loop and
there's no guarantee (or even past evidience to show) that IE's new
standards mode would be up to par.

I guess at the least, it shows the desperate need to do something about IE.

--
burnout426

Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

[Shadow2531]

On 3/10/07, Mihai Sucan <[EMAIL PROTECTED]> wrote:

actually I'm skeptical about this. First impression I had reading
the first post was "hey, do we need yet another switch?". What's
"super-duper" standards mode after all?



From 
,

I got that  the standard doctypes we have now that trigger standards
mode in IE are a problem.

It seems that even in standards mode, people expect some quirky
behavior and MS wants to retain the quirkyness even in standards mode.
If they continue to fix standards mode, they'll break way too many
sites.

It seems that they are searching for a way to trigger a real standards
mode without retaining any of those quirks and without messing with
normal standards mode.

, could be used by IE to trigger a standards mode minus
any quirks.

In short, IE's standards mode is not really a standards mode. It's
just a less quirky quirks mode. They want a way to move on with
following standards without affecting the current standards mode.

So, IE would have quirks mode, standards mode and a strict standards mode.

As for other browsers that still retain a few IE compatibilities in
standards mode, when they see , that might be their
chance to ditch any behavior that was just added in to be compatible
with IE. (but that depends)

But, mainly, it'd be a tool for MS to move on. For other browsers,
just keep the bug fixing coming.

That's what I got out of the video.

--
burnout426

Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

[Shadow2531]

 triggering super-duper, standards mode sounds great. :)

--
burnout426

Re: [whatwg] element proposal

[Shadow2531]

On 3/3/07, Geoffrey Sneddon <[EMAIL PROTECTED]> wrote:


On 1 Mar 2007, at 05:27, Shadow2531 wrote:

> On 2/28/07, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Opera has some internal expiremental builds with an implementation
>> of a
>>  element. The element exposes a simple API (for the moment)
>> much
>> like the Audio() object:
>
> I think it'd be cool if the video element *just* supported theora.

Why limit yourself to one format?


So there's only one format to worry about implementing. So everyone
using the element would be using the same format.

However, as you said, there'll be better formats in the future, which
is why I asked if it'd be better to require a base format be supported
and then the vendor could support extra ones.

However, the base format might be worthless in the future and it might
be a burden to *have* to support it.

With that said, if:

1. The spec makes no requirement on the format.
2. Vendors (at least the ones interested) agree to make their video
element support one or more of the same base formats.
3.  is used as an example in the
video element description in the spec (to suggest a format, kind of
like the audio object suggests .wav)

, what features do you want from the video element? loop, autostart,
setPosition(), events, volume etc.?

--
burnout426

Re: [whatwg] element proposal

[Shadow2531]

On 3/1/07, Håkon Wium Lie <[EMAIL PROTECTED]> wrote:

Also sprach Shadow2531:

 > I think it'd be cool if the video element *just* supported theora.

It's an interesting proposal.

Traditionally, HTML/CSS hasn't said anything about which image/icon
formats to support. Given, however, that (a) our ultimate goal is
interoperability and that (b) many video formats are impossible to
support on all devices (mostly due to legal issue), I think we should
consider your proposal.


Yes, those are the main reasons for my suggestion.

I realize that just supporting one format like theora for example
means that a lot of the current content out there couldn't be handled
by the video element. However, the video element would be new and with
it new content. It doesn't necessarily need to be compatible with
everything (as it'd be a new element).

I don't think the video element can replace OBJECT and its wide (but
messy) handling of different things. I think VIDEO should  be specific
and avoid all or most of the problems object has.

As you said, it'd be untraditional, but if the format is not
specified, I can see one browser's video element only supporting mpeg
and another only supporting wmv and another only supporting ogg and
other only support .flv etc.

With that said, if a browser can make its video element support as
many formats as it wants (which I believe most people want), I do
believe that its essential that
there be a base format that must (or strongly should) be supported.
That base format might be theora or something else.

Or, do most feel the video element should just support whatever the
browser wants and leave it at that?

--
burnout426

Re: [whatwg] element proposal

[Shadow2531]

On 3/1/07, Lachlan Hunt <[EMAIL PROTECTED]> wrote:

Shadow2531 wrote:
> On 2/28/07, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
>> Opera has some internal expiremental builds with an implementation of a
>>  element. The element exposes a simple API (for the moment) much
>> like the Audio() object:
>
> I think it'd be cool if the video element *just* supported theora.

Mandating support for a single specific video format like Theora would
be like requiring browsers to only support PNG for images.


As Martin said, Perhaps ogg can be the format required to conform.
Then other types can be supported through whatever means (native or
mapping to a plugin like wmp etc.)


> If it supports whatever the browser wants to implement, we'd have to
> do like the following I think.
>
> 
>
>


Yes, that also.


And use server-side content negotiation to determine the best one to send.

The browser could send along the list of supported MIME types in it's
accept header for video formats, like:

Accept: application/ogg, video/mpeg, video/mp4, application/mp4,
video/quicktime, */*;q=0.1


Sounds good.

--
burnout426

Re: [whatwg] element proposal

[Shadow2531]

On 2/28/07, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

Hi,

Opera has some internal expiremental builds with an implementation of a
 element. The element exposes a simple API (for the moment) much
like the Audio() object:


I think it'd be cool if the video element *just* supported theora.

If it supports whatever the browser wants to implement, we'd have to
do like the following I think.


   
   http://www.xspf.org/quickstart/>. In that case, an onvideochange
event may be in order and a VideoElement.playlistDoc could be used to
reference the playlist tree. (If for example, you wanted to grab data
out of the xml playlist.)

I assume you want the width and height attributes to be used only for
specifying the original width and height the video was made at, and
css should be used to set the width and height to a % or px etc.?

--
burnout426

[whatwg] [WF2] action="mailto:" - encoding spaces

[Shadow2531]

 (#4)

In mailto URIs, %20 represents a space.

mailto:";>
   
   


If you submit that form, "mailto:?subject=1+2"; will be passed to the
mail client instead of "mailto:?subject=1%202";. This results in "1+2"
in the subject field instead of "1 2".

Are UAs allowed to use %20 instead so things come out right, or must
mail clients decode + to a space? Thunderbird, M2, and Outlook express
don't decode +s.

RFC2368 is referenced, but it and application/x-www-form-urlencoded
that the mailto: form methods are referenced under conflict with each
other on whether a space should be encoded to %20 or +.

--
burnout426

Re: [whatwg] Pre element question

[Shadow2531]

On 1/20/07, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

In Firefox 2, Opera 9 and Internet Explorer 7 the trailing newline is
ignored as well.


Here's what I get.


Line1
Line2
Line3


(representing the newlines in the dom in escaped form)

[Page in Mac newline format]
Firefox: Line1%0ALine2%0ALine3%0A
Opera: Line1%0DLine2%0DLine3%0D
IE7: Line1%0DLine2%0DLine3%0D

[Page in *nix newline format]
Firefox: Line1%0ALine2%0ALine3%0A
Opera: Line1%0ALine2%0ALine3%0A
IE7: Line1%0DLine2%0DLine3%0D

[Page in windows newline format]
Firefox: Line1%0ALine2%0ALine3%0A
Opera: Line1%0D%0ALine2%0D%0ALine3%0D%0A
IE7: Line1%0DLine2%0DLine3%0D

So, IE7, Firefox and Opera trim the first newline after the start tag,
but don't trim the newline before the end tag.

And, Firefox is the only one that consistently gets the newlines in
the DOM right.

I just stick to:

Line1
Line2
Line3

and

Line1
Line2
Line3

so I get exactly what I want as far as the number of newlines are concerned.

--
burnout426

Re: [whatwg]

[Shadow2531]

On 1/6/07, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

I think that besides supporting  it should also support  to be referenced from usemap (not with an IDREF, but with an URI,
mind you). This is compatible with what Opera does in both HTML and XHTML,
Firefox in XHTML and Internet Explorer in HTML.

See http://simon.html5.org/test/html/image-maps/ for some demos/testcases
 from Simon Pieters on the subject.


As said:

In Opera, regardless of mime type, Opera can match usemap="#test" to
,  or .
Whether Opera uses the map element with the name or the map element
with the id depends on which one comes first in the document.

IE does the same.

For FF Minefield, it strictly only matches an id in
application/xhtml+xml and strictly only matches a name attribute in
text/html.

Allowing *both* id and name to match (in text/html at least ) per IE's
rules would be great for compatibility.

As for application/xhtml+xml and the name attribute, I don't have much
of an opinion.

Having to use name in text/html and id in application/xhtml+xml or
both if you're serving the page as text/html to some and
application/xhtml+xml to others means an extra tweak that could be
solved by allowing id to match in text/html.

Just being able to use id regardless of the mime type would be the way
to go and name can be left for just for text/html for compatibility if
we don't want to allow it for application/xhtml+xml too like Opera
does.

Now that the idref issue has been sorted out, we need to sort this
stuff out too.

--
burnout426

Re: [whatwg] [webforms] input type=emails (allow multiple email addresses in one input)

[Shadow2531]

On 1/4/07, Mihai Sucan <[EMAIL PROTECTED]> wrote:

Most email web applications have a single "To" field where the user can
write multiple comma separated email addresses, with autocomplete for each
address.

The new type value could be "emails", "email-list", or even "email-csv".

Thank you for your time.


input type=email should support a comma-separated value of email
addresses imo. To me, that's an automatic given.

But, if it's too late, then in the future, updating input type=email
or adding input type=email-csv sounds cool imo.

--
burnout426

Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?

[Shadow2531]

On 12/4/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:

Shadow2531:

Sounds like you are in agreement. But can I ask you to summarized what you'd
propose?


Not sure if I can summarize, but I can be more specific by example.

Example browser preferences:
(Default value is first value)

[Markup handling preferences]
html_with_xhtml_xmlns = parse_as_html or parse_as_xml or
parse_as_xml_only_if_in_list
xml_parser_error_fallback = show_link_to_fallback_to_html or
direct_fallback_to_html[1] or no_fallback or
show_link_even_if_no_error

[parse html as xml list]
somesite.com
someothersite.com
server.domain.tld
http://somesite.com/well-formed_xhtml_markup.html

1. A direct fallback to html would not cause a loop back to the xml
parser for an html page that was set to be parsed as XML and wasn't
well formed.

Specifically, I was mentioning that settings like the following would
be a use case for XMLisms in text/html.

[Markup handling preferences]
html_with_xhtml_xmlns = parse_as_xml_only_if_in_list
xml_parser_error_fallback = show_link_to_fallback_to_html

[parse html as xml list]
Some site or page that only serves text/html, but can be properly parsed as XML.

As you can see, it wouldn't bother anyone that didn't care (as it'd be
off by default), but for those who care and want XHTML markup treated
as XML even for text/html ( and local .html and .htm), that would be a
use case.

So, my point was that we wouldn't need a text/html5 mime type (for
example) as we could reuse the text/html type (performance issues
aside). Adding a new type I don't think would help as it's probably
not compatibile, but text/html is.

It's not possible to fully get rid of mime type dependability yet, but
judging from "Who cares what mime type it uses, let's treat it for
what it is, if possible" comments on the list, the above would have
its use. And, because the above would have its use, I can see the
usefulness of some *partial* merging of XHTML5 and HTML5.

So, I agree in the usefullness of treating xhtml markup as XML at
will. I'm just not sure that it'll work good enough and many including
Ian have already strongly suggested that it would not work good
enough.

The question probably is: if the xhtml markup is being sent as
text/html and works fine as text/html, why treat it as XML?
For me personally, I like the strictness of XML and its other rules. I
want xhtml markup to blow up if there's an error so it can be fixed.
For others, that want to use XML tools on XHTML markup (regardless of
mime type), want the errors fixed also.

Don't get me wrong and it may seem contrary to what I've said above
(just being open minded), I'm fine with serving as
application/xhtml+xml and calling it a day. I don't mind serving using
HTML markup as text/html and calling it a day. But, doing both,
especially with the same markup, I am not interested in usually.
However, I'd still like to handle pages made by others that do it.

--
burnout426

Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?

[Shadow2531]

On 12/2/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:

On another note, why not another new content type, one that would mean?:

"Striving to be XHTML, but if not consider me HTML5. And if that
doesn't work, try HTML 4.01."


If you're implying, "Treat as XML and if that fails":

One of the cool things about Opera is that if it encounters a broken
xml document, you can reparse it as HTML with a click of a link.

That means, there could be an option for browsers that support
application/xhtml+xml to treat text/html as xml ( by sniffing for a
xmlns or some other way) and then either directly or non-directly fall
back to html if there's an error.

Firefox could do the same with the yellow bar that pops up at the top
of the page that says, "The document appears to be XHTML, but is not
well formed. Firefox has reparsed it as HTML for you in an attempt to
handle the errors.", or something like that.

The problem with that would be that a lot of well-formed XHTML markup
would break if treated as XML ( because of casing rules etc.), so
you'd still want an option to reparse as HTML even if there were no
markup errors.

Sites could have a "Our pages support 'text/html as XML'  handling.
Add us to your browsers's text/html -> XML list.".

One point is that stuff like that could be done in a slick way with
the text/html type instead of a new type as we already have problems
with 2 types. (not that I believe this idea would be well accepted or
practical)

Just mentioning this though, I realize everyone's thinking, "Users
would just turn that feature off and what's the point anyway etc.???",
but I do see some benefit in the idea as a developers tool, to spread
XHTML awareness and to provide XHTML benefits with just using
text/html.

To be on topic, the other point is, that describes a (far fetched) use
case for those suggesting  *partial* integration of XML stuff in
HTML5.

--
burnout426

Re: [whatwg] xml:lang and xmlns in HTML

[Shadow2531]

On 12/1/06, Michel Fortin <[EMAIL PROTECTED]> wrote:

I wonder if xml:lang and xmlns couldn't be made legal in HTML.
xml:lang would simply become conformant in HTML as a synonym for the
lang attribute, it's already in the spec that it should get the
correct treatment anyway. xmlns would only be allowable on  and
only with the HTML namespace as its value.

This would make it possible to have documents conformant with both
syntaxes at the same time. That's assuming you don't use  or
; in the cases they're needed they'd have to be
changed to xml:base and , but that's a lot simpler to do than
to change every instance of lang in a document for xml:lang, and it
can be avoided in the vast majority of the cases.


It looks like the goal here is to serve markup like the following as
both application/xhtml+xml and text/html and have it be valid in both.



http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
   
   title
   
   
   
   
   
   
   testline1line2line3
   


Would that be the correct assumption?

If so, what is the reason for doing so?  Is this because many really
want to use XML, but don't want to get punished by the validator for
supporting IE through a text/html workaround? Or, is there something
more like being able to flip mime types without changing anything ( if
you're careful with how far you follow xml rules)?

I take it that accepting the trailing slash on void elements isn't enough.

It seems html5 could allow xmlns and xml:lang for text/html without
problem, but it still wouldn't be treated as XML, so why allow it?
Just so a validator doesn't show an error?

Or, maybe you're just saying that since a lot of XHTML markup is
*handled* in text/html by UAs, we should define it just to reflect on
current support?

Just trying to see the reason.

Thanks

--
burnout426

Re: [whatwg] Object data Attribute

[Shadow2531]

On 11/7/06, Shadow2531 <[EMAIL PROTECTED]> wrote:

On 11/6/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
> Hi,
>Should the data attribute be required for ?

No.

Reason 1:
 is used for Java. (
Although I'd love to have  work, but ...)

Reason 2:
You might want to load a plugin like this:  and later use scripting to
tell the plugin to get the resource. If the data attribute is
required, you'd be forced to load a resource that you didn't want to.

Reason 3:
The tcl plugin <http://www.tcl.tk/software/plugin/> suports inline
scripts via a script param and things like the following need to work
with the data attribute.






Note that the embed element should not require the src attribute for
the same reasons.

For example, this needs to be be allowed:



--
burnout426

Re: [whatwg] Significant inline and

[Shadow2531]

On 11/15/06, Henri Sivonen <[EMAIL PROTECTED]> wrote:

On Nov 15, 2006, at 12:19, Henri Sivonen wrote:

> Is it really intentional that the  element counts as
> significant inline content?

Map seems to be a block-level element, so I guess the question is
implicitly answered.

However, should  and  count as significant inline
content? I think not.


beginend

In Opera and IE, you'll see beginend. In Firefox quirks mode, you'll
see the same. In Firefox standards mode, you'll see:
begin
end

The default style applied to the map element varies between browser
and rendering mode.

Someone once pointed out to me that even if the map element has a
content model of block, that doesn't mean it should have a default
style of block applied to it. That is a css  issue though.

Anyway, yeh, if you put stuff inside map, it takes up space except for
 and  etc.

--
burnout426

Re: [whatwg] element: downloading a resource

[Shadow2531]

On 11/7/06, Alexey Feldgendler <[EMAIL PROTECTED]> wrote:

On Tue, 07 Nov 2006 15:39:56 +0600, Anne van Kesteren
<[EMAIL PROTECTED]> wrote:

> The definition of downloading a resource must be clear that even if the
> resource does not need to be downloaded (because it has been cached or
> something) the load event still needs to be dispatched (or the error
> event, in case it contains errors).

Even for data: URIs?


I think so. Why should a data uri image be different?


And what about

img.src = img.src;

?


I also think so because IE, Firefox and Opera 8 fire a load event for
that. Opera 9 doesn't though, but it should.

If that's not a good enough reason to fire a load | error event:

Say if  you do img.src = img.src and the image is no longer at the
address and is not cached?  You'd want it to fire an error event
right?

Also img.src = img.src doesn't fire an onchange event ( not saying it
should ) so you can't use that to tell if the img.src setter was used.
I guess you could use setAttribute and check for the attribute to be
modifed, but that still doesn't tell you when the image is fully
loaded or not.

That's my take on this.

--
burnout426

Re: [whatwg] Attribute datatypes on

[Shadow2531]

On 11/9/06, Henri Sivonen <[EMAIL PROTECTED]> wrote:

How does  allowing any attribute in no namespace interact with
attributes that are defined to apply to all elements? That is, should
datatype constraints on common attributes apply?

For example, is dir="blahblah" a conforming attribute on ?


Good question.



In this case, the dir attribute is meant to be a param that specifies
a directory that the plugin will use for whatever reason.

Are common attributes reserved and therefore can't be used as params?

Should the UA make sure it doesn't pass any common attributes to the plugin?

If no, and dir can be a param of whatever type you want, it should not
have any constraints.

Basically, would this be a correct assumption?

Common attributes are reserved. They do not act as params and should
not be passed to the plugin as params. Therefore their values still
need to follow the contraints laid out for their type.

--
burnout426

Re: [whatwg] Object data Attribute

[Shadow2531]

On 11/6/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:

Hi,
   Should the data attribute be required for ?  There is at


No.

Reason 1:
 is used for Java. (
Although I'd love to have  work, but ...)

Reason 2:
You might want to load a plugin like this:  and later use scripting to
tell the plugin to get the resource. If the data attribute is
required, you'd be forced to load a resource that you didn't want to.

Reason 3:
The tcl plugin  suports inline
scripts via a script param and things like the following need to work
with the data attribute.


  


--
burnout426

Re: [whatwg] Object data Attribute

[Shadow2531]

Me:

Reason 3:
The tcl plugin  suports inline
scripts via a script param and things like the following need to work
with the data attribute.


Sorry. Correction.  That's WITHOUT the data attribute.

--
burnout426

Re: [whatwg] element comments

[Shadow2531]

On 11/7/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

I thought the proposal was that only that (setting height and width to the
intrinsic size of the image) would be conforming, but that rendering would
still be the same.


Yeh, in example method, this is the suggestion:
(at least from what I got out of the proposal)

[conforming]



[non-conforming]




Note: For backwards-compatibility, even though these are
non-conforming, the width and or height attribute values are still
applied to the image for rendering (if css doesn't override).

[encouraged if you need to resize the image]
selectorThatMatchesTheImage {
   width: 400px;
   height: 200px;
}


[encouraged if you need to resize the image - alt]


If that's correct, doing things the proposed, encouraged, conforming
way seems fine as far as UAs that support css are concerned.

--
burnout426

Re: [whatwg] Video (Was: How not to fix HTML)

[Shadow2531]

On 10/30/06, Ian Hickson <[EMAIL PROTECTED]> wrote:

On Mon, 30 Oct 2006, Charles Iliya Krempeaux wrote:
>
> Would you be open to hearing suggestions about how to add native video
> and video player support?

Sure. FWIW, there's a lot of interest in browser vendors about introducing
a  element or some such (or maybe making browsers natively support
video in , or both).

(What's most needed right now in this area is probably implementation
experience.)


Whether it's ,  ,  , ,  or
, the data can be mapped to a handler ( either native or
some plugin).

The problem with object and embed is that they are sort of universal.
You don't know for sure what handler is going to handle the resource
and therefore don't know what params the handler supports.

( Unless type="video/html5" is used and the UA only allows that type
to be loaded for native support or its official plugin and not some
random plugin that claims support.)

Now, a  element could be specific and support specific params.
A UA that fully supports the video element would have a handler that
fully supports the params laid out in the spec and fully supports
scripting and event handling laid out in the spec.

I think the  element should support fallback content like
, but I think *maybe* no attributes should count as params (
only param elements. ).

In general, make  so there's only one way to do something. That
way you don't get:



on some pages and


   


on others.

The handler should also support some type of playlist like
. (  and the audio object should support
that too, but ... )

Just throwing up some ideas. :)

--
burnout426

Re: [whatwg] IRIs and javascript: scheme

[Shadow2531]

On 10/18/06, Christian Schmidt <[EMAIL PROTECTED]> wrote:

Most modern browsers support the following:
foo

AFAICS "javascript:alert(123)" is not a valid IRI according to RFC 3987
(it should be "javascript:alert%28123%29" instead) and is thus not
allowed in an  field. This is somewhat surprising to
me, and I think it will confuse users that they now have to manually
escape their javascript: URLs when entering them in url input fields.


In Opera, if you do , you won't be able to submit because
the parenthesis are not encoded. You have to make sure the "(" and ")"
are encoded so that the server gets javascript%3Aalert%2528123%2529,
so that when your server script decodes the data, it gets
javascript:alert%28123%29.

That makes sense to me. After your script decodes the data sent to it,
you should get a properly encoded IRI.  That won't happen if ( and )
are not represented as %28 and %29 before submitting.

If you want to allow the ( and ) to be raw before submitting, might as
well use type="text".

So, I think type="url" needs to be that strict and I think it should
require properly encoded IRIs as input.

That is a problem though as most bookmarklets ( for examlple)  are not
encoded properly, but still work, so people don't encode them or have
no clue how.

There are tools for that though.  I have
<http://shadow2531.com/opera/js/uris/jsuri.xhtml> for example that
I've been messing around with.  It uses encodeURIComponent though and
doesn't get the ( and ), but the point is, tools can be made.

Also, you could probably dynamically encode raw text  with JS as it's
entered in type="url", so it is submitted right.

So, that's just my take on why unescaped data should not be allowed.

--
burnout426

Re: [whatwg] WhatWG and

[Shadow2531]

On 9/5/06, Christian Biesinger <[EMAIL PROTECTED]> wrote:

Shadow2531 wrote:
> The FF ( trunk or 1.5.0.6) codebase problem doesn't happen with Flash
> as you can see from :
>
>  codebase="http://www.adobe.com/";
> data="shockwave/download/triggerpages_mmcom/flash.swf" width="300"
> height="120">

Hm OK. So there's probably not a general issue with codebase.


Correct


> Baseurl is a valid param for the windows media plugin.

Doesn't seem like something the browser should know or care about. Also,
the page says it's only for content embedded in the media file, I'm
reading that as it doesn't apply to the media file itself.


Original with just codebase + data ( doesn't work in FF ):
<http://shadow2531.com/opera/testcases/plugins/wmp/004.html>

Fix, which adds baseurl ( works in Firefox ):
<http://shadow2531.com/opera/testcases/plugins/wmp/004-fix0.html>

You can argue that if wmp needs a baseurl param in that situation,
that's the plugin's fault and the author of the page should take that
into account and add a baseurl, but I'm saying,  codebase + data ->
src isn't enough to make wmp object-tag -compatible in this case (
like it is with other plugins ). Meaning, if wmp is object tag
compatible, codebase + data should be all you need to load the file.

Can someone get MS to fix that?


> So workarounds are done in the same way, so the same markup works
> arcross browsers in the same way.

It does. It works the same way in all NPAPI browsers, and if the plugin
vendor is sensible also in all ActiveX-using browsers. And it would be
much nicer if workarounds were not in place at all :)


Yes, I'd rather zap all workarounds.

Thanks

--
burnout426

Re: [whatwg] WhatWG and

[Shadow2531]

On 9/5/06, Christian Biesinger <[EMAIL PROTECTED]> wrote:

Shadow2531 wrote:
> However, see <http://shadow2531.com/opera/testcases/plugins/wmp/004.html>

I don't have a WMP plugin (or a Windows OS, at the moment), do you have
maybe a flash testcase? Also: which version of Firefox did you test with?


The FF ( trunk or 1.5.0.6) codebase problem doesn't happen with Flash
as you can see from :

http://www.adobe.com/";
data="shockwave/download/triggerpages_mmcom/flash.swf" width="300"
height="120">


> Either way, it works in Opera, but the difference is that with the
> latter, the plugin itself does the resolving.  If you actually want
> the plugin itself to do the resolving, and the plugin doesn't know
> codebase, I think you should be allowed to make things work.

I absolutely don't think this should be up to each implementor. And I
don't think the spec should require it either. Where does this baseurl
attribute come from anyway? I can't seem to find docs on it.


Baseurl is a valid param for the windows media plugin.

See 
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmplay10/mmp_sdk/paramtags.asp>
and <http://msdn.microsoft.com/library/en-us/wmp6sdk/htm/player6baseurl.asp>
for example. The base param works for the netscape 6.4 version also.


> It's the wmp netscape plugin and MS's documentation that's the
> problem, but they're never going to fix it, which is why I think it
> should be allowed to make things work even if it is the plug-ins
> fault.

Why are they never going to fix it? And why should the browser work
around it?


"never"= "it doesn't look like they are going to fix it, since they
haven't after all this time".

It would be good for the browser to workaround it because the plugin
maker won't and what's important is to make things work. In other
words, if they won't fix it, we could say, "oh well, it's the plugin's
problem, not ours", but that doesn't help anything.

Problem is, a browser can't just go off fixing things unless the
others are on board and that may only happen if there's something to
follow.


> To sum things up, there needs to be a set or common way of making
> pain-in-the-butt plugins work, but again, I guess this is beyond the
> spec.

Why does there _need_ to be such a way?


So workarounds are done in the same way, so the same markup works
arcross browsers in the same way.

Since I know you're not convinced, I'll leave it at that, but if
anyone has some MS and Real contacts, maybe we can finally get things
fixed and not worry about this.

--
burnout426

Re: [whatwg] WhatWG and

[Shadow2531]

On 9/5/06, Boris Zbarsky <[EMAIL PROTECTED]> wrote:

Shadow2531 wrote:
> If Firefox does use codebase to resolve data for WMP before mapping to
> src

It does.


cool


> Right-clicking on the wmp window and choosing "error details" -> more
> information, will show "C00D1197: Cannot play the file". That's
> because WMP most likely only got "opera/testcases/plugins/wmp/000.wax"
> passed to it for the src param.

Most likely, or definitely?   Before you said definitely.


I don't know. I have no way to test what the plugin actually gets, so
most likely.


> Or, if Firefox downloads the file itself and then passes the local
> path of the file to the plugin

This is what it does, yes.

> something may be wrong there. ( Not
> sure as I don't know how it's done exactly. )

Does the plugin expect .wax files?  Or some other extension?


Yes. audio/x-ms-wax and the .wax extension are valid for the WMP plugin.

--
burnout426

Re: [whatwg] WhatWG and

[Shadow2531]

On 9/5/06, Boris Zbarsky <[EMAIL PROTECTED]> wrote:

Shadow2531 wrote:
> However, see <http://shadow2531.com/opera/testcases/plugins/wmp/004.html>
>
> That works in Opera, but doesn't in Firefox. It seems that Firefox  is
> not using the codebase to resolve the data attribute before mapping it
> to src.

Which Firefox version?  I see Firefox doing:

GET /opera/testcases/plugins/wmp/000.wax HTTP/1.1
Host: shadow2531.com

in a current trunk (Minefield) build.


Before posting that, I tried in Minefield and 1.5.0.6 just to make
sure. They both fail to play the file.

If Firefox does use codebase to resolve data for WMP before mapping to
src, then the WMP plugin should get
http://shadow2531.com/opera/testcases/plugins/wmp/000.wax for the src
param value, but it doesn't look like that's what the plugin gets as
you can't play the file in Firefox.

Right-clicking on the wmp window and choosing "error details" -> more
information, will show "C00D1197: Cannot play the file". That's
because WMP most likely only got "opera/testcases/plugins/wmp/000.wax"
passed to it for the src param.

Or, if Firefox downloads the file itself and then passes the local
path of the file to the plugin, something may be wrong there. ( Not
sure as I don't know how it's done exactly. )

Hope that helps.

--
burnout426

Re: [whatwg] WhatWG and

[Shadow2531]

On 9/4/06, Christian Biesinger <[EMAIL PROTECTED]> wrote:

Shadow2531 wrote:
>> > "The UA may ignore the codebase if it is determined that it does not
>> > contain a base IRI".  Basically, ignore codebase if it has known URIs
>> > to cab files etc. in it.
>>
>> Ew...
>
> As in "No way!" or 'Ew' as in "I hate that IE does that!" or other?

"Ew" as in "I wouldn't want to see that text in any spec".


O.K. Thanks


> It's O.K., if it makes the plugin work, which is what matters. If the
> plugin doesn't know what 'data' is, you map it to something else like
> 'src'. If the plugin doesn't know what 'codebase' is, you map it to
> something else like 'baseurl' in the case of WMP.

Gecko maps data to src (in case of ), but that's all. It
certainly doesn't map codebase to anything else.
> As for the priority deal. Here's an example:
>
> http://somesite.com/dir/";>
>http://someothersite.com/";>
> 

See above re codebase. (Although, note that Gecko uses codebase as the
base URI for resolving the data attribute, and it passes the data it
receives from the resulting URI to the plugin).


Yes, codebase + data -> src is great and universal.

However, see <http://shadow2531.com/opera/testcases/plugins/wmp/004.html>

That works in Opera, but doesn't in Firefox. It seems that Firefox  is
not using the codebase to resolve the data attribute before mapping it
to src.

Opera either does codebase + data -> src , or it does codebase ->
baseurl (for wmp only) and data -> src and lets the wmp plugin do the
resolving.

Either way, it works in Opera, but the difference is that with the
latter, the plugin itself does the resolving.  If you actually want
the plugin itself to do the resolving, and the plugin doesn't know
codebase, I think you should be allowed to make things work.

Now as for the priority question, I just answered my own question.  If
doing codebase + data -> src  ( like Firefox does or is supposed to do
) for WMP, the baseurl param wouldn't matter. That would mean in the
situation of codebase -> baseurl and data -> src, if baseurl is
present it would not matter and codebase gets priority.

With said, there could be something in the spec about that, but I
believe it's implied now by codebase + data rules, so I drop the
suggestion.


> Should browser's be allowed to map false|true to 0|1 on a
> plugin-by-plugin basis in this case to make things work?

On a plugin-by-plugin basis? That would be insane, IMO. Why make
browsers do this? Only the plugin itself knows how to interpret a
certain parameter value. The browser doesn't even know the data type.

>> Presumably it's the plugin itself that handles those attribute mappings.
>
> Sometimes we know better than the plugins.


Yes, the WMP plugin handles the params itself, but only with activex
does it accept true/false. With the netscape version, it's 1/0. Now
that's not a big deal if you use totally separate params for each
version, but if you want to use the same params for both, it's a
problem if the activeX plugin interface doesn't map 1|0 to true|false.
Besides, Microsoft's documentation says it should be true/false.

It's the wmp netscape plugin and MS's documentation that's the
problem, but they're never going to fix it, which is why I think it
should be allowed to make things work even if it is the plug-ins
fault.

In other words,  1 and false -> 0 before passing to wmp
at one time, but that has changed. If I can find a bug report on that,
I'll certainly show you, but it's not important as Firefox doesn't do
that anymore.

To sum things up, there needs to be a set or common way of making
pain-in-the-butt plugins work, but again, I guess this is beyond the
spec.


OK, can you point me to the code in Gecko that does the mappings you
mentioned? (except the data/src one, which is at
http://lxr.mozilla.org/seamonkey/source/layout/generic/nsObjectFrame.cpp#2477)

> There's just too much undefined behavior when it comes to
> object/embed. Let's add some detail. :)

Seeing as I don't think current browsers do most of those mappings, I
don't quite see the point of specifying them...


Yeh, see above.  Thanks

--
burnout426

Re: [whatwg] WhatWG and

[Shadow2531]

On 9/1/06, Christian Biesinger <[EMAIL PROTECTED]> wrote:

Shadow2531 wrote:
> Yes, it's arguably a bug, but I do like this bug because I can use
> only one object element to do IE's classid way and the normal way.
> It's a compatibility feature imo.  However, I can't use it in
> production without breaking FF or adding alternate content or doing IE
> conditional comments or other ways.   ( IE doesn't like nested objects
> very well without some css hacks. )

Personally I don't mind the  way really :)


:) Yeh, it's not THAT bad.


>  type="type" data="file.ext">
> 
> 
>
> could be an answer to this.

I'd rather see IE work without specifying classid, then this would work
without any new attributes...


Oh, same here.


> Maybe Mozilla can compromise for IE-compatiblity. If not, we need the
> spec to say specifically that classid must be tried first and using
> the data attribute after that must not happen.  ( It's seems there are
> interpretation differences with the current spec and I'd like there to
> be no doubt what should happen.  Then, we can fix bugs.)

I would like the spec to say that, indeed. (A while ago I asked a few
questions about how  should behave on this list, btw).
> Also, IE's current use of  the codebase attribute is of course wrong
> according to HTML 4.01.  I'd like to see something in the spec like
> "The UA may ignore the codebase if it is determined that it does not
> contain a base IRI".  Basically, ignore codebase if it has known URIs
> to cab files etc. in it.

Ew...


As in "No way!" or 'Ew' as in "I hate that IE does that!" or other?


> Also, I'd like to see mention in the spec that it is O.K. to map
> object element attributes to other params for plug-ins that don't
> conform to object element handling. For example, mapping codebase ->
> baseurl and data -> filename for WMP. I'd also like to have it spelled
> out what happens with mapping if both codebase and baseurl are
> present.  (Like which one gets priority )

Why is that OK? Which browser does that? And why not specify that either
way must be done, instead of allowing both?


It's O.K., if it makes the plugin work, which is what matters. If the
plugin doesn't know what 'data' is, you map it to something else like
'src'. If the plugin doesn't know what 'codebase' is, you map it to
something else like 'baseurl' in the case of WMP.

An example that Firefox and Opera both do:
<https://bugs.helixcommunity.org/show_bug.cgi?id=4766>

I'd like the spec to describe exactly how browsers should do stuff like that.

As for the priority deal. Here's an example:

http://somesite.com/dir/";>
   http://someothersite.com/";>


If the browser must map codebase to baseurl for a certain plugin like
WMP to work with the object element, if both are specified, does the
codebase still map to baseurl or can the browser give the actual
baseurl priority and not map. It could be done a few different ways.
All I'm saying is I'd like it spelled out so everyone can stick to it.

Another example WMP example:



does nothing for the WMP netscape 6.4 plugin that Opera and Firefox
(normally) use.

Instead of 'false', it has to be '0'.

Should browser's be allowed to map false|true to 0|1 on a
plugin-by-plugin basis in this case to make things work?

I know it's MS's fault for this or Real's fault in the other case, and
there are markup ways around it, but I'm saying that browsers have to
do all kinds of things to make plugins work, because most plugins
suck.

The thing is, if all browsers are not working around the problems is
some common way, it doesn't help. If half are using duct tape and half
are using elmer's glue, we're still stuck with cross-browser
incompatibility.

Maybe this stuff is beyond the spec, but I bring it up for everyone to decide.


Presumably it's the plugin itself that handles those attribute mappings.


Sometimes we know better than the plugins.

There's just too much undefined behavior when it comes to
object/embed. Let's add some detail. :)

--
burnout426

Re: [whatwg] WhatWG and

[Shadow2531]

On 8/21/06, Boris Zbarsky <[EMAIL PROTECTED]> wrote:

Shadow2531 wrote:
> If classid and data are both present, Firefox ignores the data and
> gives the classid a shot. If there's no activex plug-in installed that
> handles the clsid, Firefox fails and goes to alternate content.

You mean "type", not "data", right?  And actually, all non-java classids just
make Firefox show the alternate content, unless you have the optional ActiveX
stuff installed.


Type may be required to trigger that behavior, but yes we're talking
about the same thing.


> It looks like you're saying that people that target the activeX method
> don't want to fall back on the NPAPI method.  But, what if an author
> wants to?  You'd probably say to use alternate content and another
> object tag or embed tag.

Yep. That's the whole point of  having alternate content.

> However, I think it'd be neat to fall back (or give the option through
> an attribute or something to fall back ) on the data off the current
> object element.

Why reinvent the wheel?  There is already a way of doing fallback with .
> Opera doesn't do classid stuff (except for java) so it can ignore the
> classid and use data.

In my opinion, this is a bug in Opera; one they introduced to be more compatible
with IE in many cases (and that breaks other cases, sometimes badly).


Yes, it's arguably a bug, but I do like this bug because I can use
only one object element to do IE's classid way and the normal way.
It's a compatibility feature imo.  However, I can't use it in
production without breaking FF or adding alternate content or doing IE
conditional comments or other ways.   ( IE doesn't like nested objects
very well without some css hacks. )

For example:




Something like that would work fine in both IE and Opera. In Firefox
that would break if there wasn't an activeX plug-in installed to
handle that particular clsid.

Now:




could be an answer to this.

fallondata would allow the author to choose the compatible way like
Opera does, but not using fallondata would allow the author to do
things the normal why like FF.

Compatibility and control are the use-cases for fallondata. I wouldn't
consider it reinventing.

Maybe Mozilla can compromise for IE-compatiblity. If not, we need the
spec to say specifically that classid must be tried first and using
the data attribute after that must not happen.  ( It's seems there are
interpretation differences with the current spec and I'd like there to
be no doubt what should happen.  Then, we can fix bugs.)

Also, IE's current use of  the codebase attribute is of course wrong
according to HTML 4.01.  I'd like to see something in the spec like
"The UA may ignore the codebase if it is determined that it does not
contain a base IRI".  Basically, ignore codebase if it has known URIs
to cab files etc. in it.

Also, I'd like to see mention in the spec that it is O.K. to map
object element attributes to other params for plug-ins that don't
conform to object element handling. For example, mapping codebase ->
baseurl and data -> filename for WMP. I'd also like to have it spelled
out what happens with mapping if both codebase and baseurl are
present.  (Like which one gets priority )

On a side note, what do you think about mayscript for the object element?

Currently, for applet -> js communication, this is how I need to do it in Opera:




Does FF need that or does the java plugin automatically allow applet
-> js communication.

Mayscript is something we might need to define.

Thanks

@Christian
Sorry to mix in some object element stuff into your embed discussion,
but object kind of gets implied when you mention embed.
--
burnout426

Re: [whatwg] WhatWG and

[Shadow2531]

On 8/20/06, Dave Bacher <[EMAIL PROTECTED]> wrote:

Shadow2531 wrote:
> On 8/18/06, Christian Biesinger <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I got a question about . Firstly, does WhatWG intend to document
>> that element and how it works?
>>
>> Secondly, if so:
>> Consider an . Consider that said system has a
>> plugin installed that can show movies in that format (that is,
>> video/x-ms-wmv). The plugin can also handle "*.wmv" movies.
>>
>> Now, imagine that the server sends a type of text/plain for this file.
>>
>> What should happen?
>
> If text/plain is sent, I expect it to fail unless you have a
> text/plain plug-in installed. Even then though, the video wouldn't
> play because it'd be a text/plain plug-in, not a video plug-in..
> However, if no type at all is sent ( like if you're loading a local
> page that embeds a local wmv file), then I'd say use the extension as
> a backup.
This is inconsistent with how the object tag in HTML 4.01 interprets the
attribute.  In HTML 4.01, the object tag only receives a content type in
three cases:
1.  The content type cannot be determined based on the classid attribute
2.  The content type is not provided by the transport mechanism at all
(note: HTML cannot assume HTTP transport -- it is also transported by
FTP, SMTP, POP3, IMAP, WebDav and other mechanisms -- content type is a
concept not supported by some of these, notably FTP).
3.  The content type provided by the transport mechanism is incorrect

My opinion is since the embed tag is a non-standard precursor to the
HTML 4.01 object tag, that if it is supported at all (and it really
shouldn't be -- object provides the same functionality and is widely
supported now), that it should follow the exact same rules as the HTML
4.01 standard places on the object tag.


Making embed do as object ( minus the alternate content of course
since embed is an empty element  and noembed isn't the same) would be
a good idea. I think some things with the object element need to be
sorted out as well though.


First, HTML is transport independent.  If an HTML file is viewed via
FTP, for example, there won't be a content-type at all.  You cannot
assume HTTP + HTML, you have to assume that other newer or older
protocols could be used to provide the HTML content.


Point taken. If those cases, use extension or other means to determine
the action.


Second, many applications and sites are hosted on providers such as
GoDaddy, Earthlink, GeoCities, AngelFire, AT&T Global Services, etc.
where the page author has extremely limited control over the server
configuration, if any control at all.  As a result, the HTML standard
supports HTTP-EQUIV as a meta tag for overriding or flat out providing
information that should be in HTTP headers.  This kludge is because of
these kind of providers.


True.  The type attribute could be used as a backup in these cases. (
But see my reply to Boris Zbarsky)


My argument is this:
1.  The embed tag is redundant with the object element, and the object
element is now widely supported.  New pages should not use embed, they
should use object.


I like this idea, but I don't deal with netscape 4.8 etc. I suppose
many still do.


2.  If you want to add the embed element to an HTML 4.01 standard, then
its handling of content type should in every way match the handling of
the content type by the object tag, because there is no reason why it
should apply different (more or less) restrictive rules than a directly
equivalent tag.


O.K. Syncing object and embed handling sounds good to me. Currently,
they are not handled exactly the same.


3.  It should always be assumed that the web server and its
configuration are outside the page author's control.  HTML standards,
which are not tied to any specific transport mechanism, should be built
around that concept.  There should be no differences in behavior because
of content type, aside from potentially using a XML parser in place of
the HTML parser by default for an XML data type.  Even in that case, the
browser should fall back on the HTML parser if it fails (because the
user isn't the one who made the mistake, and you are penalizing the user
for using an up-level client -- the user will soon learn to install and
stick with a down-level client, so that you don't interfere with their
browsing).


This is where I myself would like to invoke strict handling ( via some
attribute ) as I might want things to fail if the proper content-type
is not sent.

 might not do me any good if file.php doesn't
send the right content-type.

I can see something like this:



where that would fail if file.php isn't sent as audio/x-ms-wax.

To stress again, I know we don't want to break current handling, but
we definitely need to straighten some things out.

Thanks

--
burnout426

Re: [whatwg] WhatWG and

[Shadow2531]

On 8/21/06, Boris Zbarsky <[EMAIL PROTECTED]> wrote:

Note: I'm not on the whatwg mailing list, so please cc me on replies.

Shadow2531 wrote:
> If text/plain is sent, I expect it to fail unless you have a
> text/plain plug-in installed.

Does that match current UA behavior?


No. The file will still be played.

I expect it ( not necessarily saying I want it ) to fail because the
Windows Media plug-in in this case does not report that it supports
playing text/plain media. It says it supports the .wmv extension, but
what if I have a text/plain plug-in? Will it load in the plug-in
associated with text/plain or in the windows media plug-in or other?

I'd like to see the steps spelled out *exactly* because HTML 4.01 does
not do that.

Also, what about this  (where the asx file is
served as text/plain).  What if I really want it embedded as a text
file and don't want it embedded with the wmp plug-in?


> I think the type attribute should be required though

Again, does that match current UA behavior?


No. Things usually work without a type attribute.

I think it should be encouraged though. It does have it's uses.

It's a great hint if the browser can't figure out what to do with the
mime type sent, if any, and the extension doesn't help.

Also, whether it currently works correclty this way or not,
type="application/x-mplayer2" for example means to load the src with
the windows media plug-in regardless of the the extension or type and
leave it up to the plug-in to decide whether the file is supported.

For example, 
should load with the windows media plug-in and will in Firefox.
However, in Opera, it might load as just a gif file unless the gif
file is sent as application/x-mplayer2.

Also,  without a src could be used to invoke a
plug-in for scripting so that scripting could set a source.

Maybe having a nosrc="true" attribute would please me for this.

Also, ( this is more with the object element ), if I specify a type=""
and the server sends the file with a type that doesn't match, I might
want the alternate content to display.

Those are just some reaons for the type attribute.  Of course you
might say then, "If that's so, do you think the type attribute for A
should be required too?". I'd  say, "no".


> and things should fail if the type sent by the server doesn't match the type 
attribute.

Why?


If the type attribute is required and things failed if the server
content-type doesn't match, then maybe we wouldn't have so many people
embedding files sent with the wrong type.

Maybe having a strict="true" for that would please me.

We also don't want to give the plug-in something that it doesn't say
it supports. Unless we want to give it everything and let it sort
things out.

We need some type of standard for plug-in development too as most
plug-ins don't use a data param and browsers have to map it to a src
param.


> Basically, the browser should follow the rules of the plug-in and only
> invoke the plug-in for types and extension the plug-in says it
> supports.

Sure, but the question is how one should decide what type to use for the data in
question.


*That* is exactly what I would like spelled out. Something specific
that all browsers can follow because I think things are quite chaotic.

I know we can't break pages, but I believe strict handling of things
would be better in the long run. That's not for me to decide alone
though of course.


> Your text/plain example is a good example. If you embed a .wmv file,
> we know no matter what it's sent as

It's sent as text/plain.  Always.  Thank you, Apache!


.htaccess will take care of that and we should encourage people to
change things to be sent with the correct type any time possible.


> Making  ( sent as text/plain ) fail may
> seem evil, but it might be for the better.

Better what?


Better for the web. Take XML for example. If your markup isn't right,
you'll know it when the browser parses it. You are then basically
forced to have it right or it won't work.  Making things strict with
embedding would straighten a lot of these nasty web sites out. Again,
I believe it'd be better in the long run, but I'm torn between doing
that and making everything work no matter how incorrect things are.


> I'd like to forget about the embed element

Not acceptable --  is the one existing sanely cross-browser way of doing
plugins.


Yep, but I don't like it. :)


> ( And explicitly say that it's O.K. for a UA to
> ignore a classid it doesn't support and use the data attribute
> instead, for Mozilla's benefit.)

Also not acceptable (speaking as a Gecko developer) -- we don't want to deal
with the issue that will arise when content meant for ActiveX plugins gets sent
to NPAPI ones, which have differe

Re: [whatwg] WhatWG and

[Shadow2531]

On 8/18/06, Christian Biesinger <[EMAIL PROTECTED]> wrote:

Hi,

I got a question about . Firstly, does WhatWG intend to document
that element and how it works?

Secondly, if so:
Consider an . Consider that said system has a
plugin installed that can show movies in that format (that is,
video/x-ms-wmv). The plugin can also handle "*.wmv" movies.

Now, imagine that the server sends a type of text/plain for this file.

What should happen?


If text/plain is sent, I expect it to fail unless you have a
text/plain plug-in installed. Even then though, the video wouldn't
play because it'd be a text/plain plug-in, not a video plug-in..
However, if no type at all is sent ( like if you're loading a local
page that embeds a local wmv file), then I'd say use the extension as
a backup.

I think the type attribute should be required though and things should
fail if the type sent by the server doesn't match the type attribute.
An exception would be the generic types like application/x-mplayer2 ,
which are allowed to embed more than one type or any type ( because
they support more than one type. )

Also note that some plug-ins like the real plug-in are very picky.
Unless you have a modified one, not only does the file have to be sent
as audio/x-pn-realaudio-plugin, but it has to have an .rpm extension.
If you have rpmfile.php for example that sends
audio/x-pn-realaudio-plugin, you'll be lucky if it works because the
extension is .php instead of .rpm. It can be that picky.

Basically, the browser should follow the rules of the plug-in and only
invoke the plug-in for types and extension the plug-in says it
supports.

Your text/plain example is a good example. If you embed a .wmv file,
we know no matter what it's sent as, it's most likely a video. In
situations like these, it might be best to make it work.

Now,  on the other hand :), having browsers go out of their way to
make things work makes it all that more O.K. to send files with the
wrong type, which we don't really want.

Making  ( sent as text/plain ) fail may
seem evil, but it might be for the better.

I'm kind of undecided. I'd like to see a lot of discussion on all this.

I'd like to forget about the embed element and just stick with the
object element though. ( And explicitly say that it's O.K. for a UA to
ignore a classid it doesn't support and use the data attribute
instead, for Mozilla's benefit.)

--
burnout426

Re: [whatwg] parsing: bogus comments - PIs

[Shadow2531]

On 7/18/06, Ian Hickson <[EMAIL PROTECTED]> wrote:

On Mon, 17 Jul 2006, Shadow2531 wrote:
>
> 
> So,  is a bogus comment.
> <http://whatwg.org/specs/web-apps/current-work/#bogus>
>
> "Emit a comment token whose data is the concatenation of all the
> characters from the character that caused the state machine to switch
> into the bogus comment state, up to the last consumed character before
> the U+003E character..."
>
> I *was* 100% sure that the PI should be parsed into:
>
> 

Correct.


Thanks Ian. Can  you comment on innerHTML for this situation?

If  is parsed into
 , what should
innerHTML show?

Currently, Gecko and KHTML ignore PIs in text/html, and don't add them
to the DOM. Plus, they don't show up in innerHTML.

Opera currently treats PIs as PIs in text/html and shows them as PI
markup with innerHTML. ( There's a tiny, already-filed bug with PIs
and innerHTML, but when the fix is applied, Opera will show
 again for the PI mentioned
here with innerHTML)

IE6 treats PIs as comments, which is good, but for innerHTML, IE6
shows the original markup of the PI instead of commented markup.

As you can see, there's nothing consistent across browsers with this
situation, but it seems that IE comes closest to HTML5.

I myself believe that if the PI is parsed into a bogus comment,
innerHTML should show comment markup as that's what it ends up being.
However, that would be incompatible with IE's innerHTML if that
matters.

What do you think?  I know innerHTML isn't yet defined, but this might
be a case where you, right now,  100% for sure,  know what must
happen.

Thanks

--
burnout426

Re: [whatwg] parsing: bogus comments - PIs

[Shadow2531]

On 7/18/06, Ian Hickson <[EMAIL PROTECTED]> wrote:

On Mon, 17 Jul 2006, Shadow2531 wrote:
>
> 
> So,  is a bogus comment.
> <http://whatwg.org/specs/web-apps/current-work/#bogus>
>
> "Emit a comment token whose data is the concatenation of all the
> characters from the character that caused the state machine to switch
> into the bogus comment state, up to the last consumed character before
> the U+003E character..."
>
> I *was* 100% sure that the PI should be parsed into:
>
> 

Correct.


Thanks.


> However, after rereading that section a few more times, I'm not 100%
> sure whether the 2 ? are included in the concatenation or not?
>
> I know it says from ? up to ?, but I might be interpreting 'from' and
> 'up to'  incorrectly.
>
> Can someone clarify?

I've tried to clarify the spec. Let me know if it's still ambiguous.


There we go. That helps big time.

Thanks

--
burnout426

[whatwg] parsing: bogus comments - PIs

[Shadow2531]

 is a bogus comment.


"Emit a comment token whose data is the concatenation of all the
characters from the character that caused the state machine to switch
into the bogus comment state, up to the last consumed character before
the U+003E character..."

I *was* 100% sure that the PI should be parsed into:



However, after rereading that section a few more times, I'm not 100%
sure whether the 2 ? are included in the concatenation or not?

I know it says from ? up to ?, but I might be interpreting 'from' and
'up to'  incorrectly.

Can someone clarify?

--
burnout426

Re: [whatwg] [html5] HTMLMapElement.images

[Shadow2531]

On 7/1/06, dolphinling <[EMAIL PROTECTED]> wrote:

Can you even have an image map on an  ?


Yes

--
burnout426

[whatwg] CDATA - white space handling for param element values

[Shadow2531]

CDATA - white space handling for param element values

<http://www.w3.org/TR/html4/struct/objects.html#h-13.3.2>
<http://www.w3.org/TR/html4/types.html#type-cdata>

The current CDATA spec is:

1. Replace character entities with characters,
2. Ignore line feeds,
3. Replace each carriage return or tab with a single space.
4. User agents may ignore leading and trailing white space in CDATA
attribute values

I think #2, #3 and #4 should be dropped for a param element's value
attribute when defining things for HTML5.

A plug-in loaded with the object element might expect and accept
parameter values with Carriage returns, Line Feeds and Tabs. The
plug-in might accept leading and trailing white space.  Normalizing
the white space can be undesired in these cases. Using entities
instead of physical white space does not help the situation because of
#1, but #1 is still very useful.

A use case for passing in newlines is the tcl plug-in.
<http://www.tcl.tk/software/plugin/>

You can load inline tcl scripts with:

   


With tcl, it is common to separate commands with newlines (as opposed
to semi-colons, which works too.). If newlines are stripped, it can
cause the plug-in to receive broken code. The xstandard plug-in may
encounter this at some point, not sure.

For an example of how following CDATA rules breaks things, see the
following in Opera (with the tcl plug-in installed and set up):
<http://shadow2531.com/opera/testcases/plugins/tcl/000.xhtml>

The tcl plug-in will receive a broken script because the Line Feeds
are stripped. You can workaround *this* problem by using semi-colons
instead of newlines:
<http://shadow2531.com/opera/testcases/plugins/tcl/000-fix1.xhtml>

This problem could break other plug-ins too.  The only real workaround
is to have to encode the value, pass it to the plug-in and have the
plug-in decode it. (if it can)

Since object element attributes can be params to plug-ins also, the
white space in their values should also not be normalized. However,
exceptions should be made for reserved attributes like: data, classid,
type, codebase, id, name, archive and possibly width and height. The
same type of thing should also be applied to the embed element.

Now, the reason I said to test the inline tcl script with Opera is,
Opera is the only browser that I've found to follow the CDATA specs
for the param element's value attribute. IE, Konqueror and Safari just
do character entity replacement and that's it. Firefox does like IE
except that it normalizes leading and trailing newlines and tabs.
However, Firefox strips newlines and tabs everywhere when passing to
the java plug-in for some reason.

IE's way of just doing character entity replacement and leaving all
white space in tact is what is really desired here.

You can check <http://shadow2531.com/opera/testcases/cdata/000.html>
in different browsers to see the differences in the handling of white
space for the param element's value attribute.

Questions:

1. For which attributes, for which elements should we allow white
space to stay in tact.

2. What procedure should be followed to get the value of an attribute
that may contain white space that should not be normalized?

For question #2, my answer is, "Do what IE does.".

On a side note, anyone know why Firefox strips all newlines when
passing to java?

--
burnout426

Re: [whatwg] [html5] HTMLMapElement.images

[Shadow2531]

On 6/13/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

Before I forget about this hereby a proposal to give the
HTMLMapElement interface a new (readonly) member called `images` or
equivalent representing an HTMLCollection consisting of
HTMLImageElement and HTMLObjectElement (and perhaps
HTMLCanvasElement?) elements that use that image map definition.


Do you want the INPUT element in the collection too? (because of type="image")

--
burnout426

Re: [whatwg] oninput event - pasting

[Shadow2531]

On 6/8/06, Ian Hickson <[EMAIL PROTECTED]> wrote:

On Thu, 8 Jun 2006, Shadow2531 wrote:
> Specifically, if I have this:
> 
>
> , and right-click and paste into the textarea or ctrl+v into the
> textarea to paste,  or select and cut, should the event fire?

Yes.

Another part of the spec mentions that the UA may coallesce multiple
inputs into one input event, so e.g. if you type very fast it might not
fire one input event per character, it might fire one every few hundred
milliseconds instead.


Thanks.

--
burnout426

[whatwg] oninput event - pasting

[Shadow2531]

"this specification introduces the input event. This event is fired on
a control whenever the value of the control changes due to input from
the user"

Does "due to input from the user" mean that *every*, *direct* action
the user *makes on the control* (that changes its value) causes the
event to fire?

Specifically, if I have this:


, and right-click and paste into the textarea or ctrl+v into the
textarea to paste,  or select and cut, should the event fire?

I can assume that, the event should fire no matter how the user
changes the value (just as long as it's done directly and not by
invoking a script that changes the value), but I'd like to know for
sure.

Thanks

--
burnout426

Re: [whatwg] Audio(): loop() with 0 or negative value as argument

[Shadow2531]

On 5/26/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

In Opera we now throw INDEX_SIZE_ERR when someone calls loop(x) on the
Audio object with x being either 0 or negative. This seems to be
consistent with how similar "errors" are treated in the 
interface and makes sense to us. Our suggestion would be to put this
into the specification, unless someone has a better suggestion.

(Note that loop() without arguments can be used for infinite repetition.)


I might seem picky, but I don't really like how loop() takes a
*playcount* param.

loop() = infinite
loop(1) = play once
loop(2) = play twice

It's the loop(n) that bugs me. I see loop(1) and think that the file
is going to play once and then loop once. (The first time it plays is
not a looped play.)

Luckily, I saw the spec and read that the parameter is NOT how many
times to loop, but how many times to play, hence *playcount*.

Not seeing the spec, if I wanted to *specifically* set the file to
only play once, I'd do loop(0), which to me would mean, play once and
not loop at all. Loop is usualy a boolean value anyway.

The following makes more sense to me:

playcount() = infinite
playcount(1) play once
playcount(2) play twice
playcount(-x) throw error
playcount(0) throw error ( Or don't throw an error and just don't
play. Can't think of a use case for that, but maybe someone can.)

On a side note, the Windows Media Plugin param PlayCount works like this:

playcount = 0 - infinite
playcount = n - number of times to play

I can see people doing loop(0) to try to turn off looping if they
previously set loop(99) for example. Getting rid of loop() and using
playcount() would clear things up IMO.

Of course, I could just be crazy. :)

I agree though, an error should be thrown for loop() for anything less than 1.

--
burnout426

Re: [whatwg] The embed element

[Shadow2531]

quoting me:

That loads a Java applet and shows Javascript<-->Java communication.
That's not possible in Opera and Firefox if you use the object element
to load the applet.
(It even works in IE, so you can test it there too.)


To clarify, I meant that the test case that uses  works in IE.

--
burnout426

Re: [whatwg] The embed element

[Shadow2531]

On 4/26/06, Ian Hickson <[EMAIL PROTECTED]> wrote:

I don't envisage keeping  around unless someone can specify it in
enough detail and give a convincing case for its inclusion.


At the least, Opera and Firefox can not expose java methods in an
applet to javascript when you use the object element.  must be used.

For example:
<http://shadow2531.com/opera/testcases/plugins/java/002.html>

That loads a Java applet and shows Javascript<-->Java communication.
That's not possible in Opera and Firefox if you use the object element
to load the applet.
(It even works in IE, so you can test it there too.)

So, currently, there's a need for  and the mayscript attribute.

Another example:
<http://my.opera.com/burnout426/homes/files/wmp_netscape_scripting.zip>

That shows how to make Windows Media Plug-in methods and its callback
events available to javascript ( In Opera 9 win32 builds at least. ) .
It loads an applet for npds.zip, which exposes the plug-in methods.
Again, it doesn't work with  because  doesn't expose
scripting of applets.  is supposed to be used in place of , but that can't
happen in all situations currently.

Even if  supported exposing applet methods to javascript, how
would you turn it on.? HTML4 doesn't define 'mayscript' for 
and nothing defines 'mayscript' for .  Should it be some
HTMLObjectElement.mayscript method?

As for , if it behaved just like  (minus the param
elements), that would be great. Currently,   is an empty
element though.

The problem with  is that it doesn't support fallback content.
There's , but that's only for when the  element itself
is not supported (because you have plugins turned off in your browser
or something.).  Plus,  isn't really tied to any certain
.

Another thing to make clear is, the default width and height.  Opera
for example currently gives a default height and width that looks to
be about the same size as a default java applet size. In Firefox, if
you don't set a width and height, they are 0.

Also,  in Opera doesn't collapse in situations like this:
http://filenotfound"; width="1000" height="1000">

You just get a big plug-in content area on the page.

There needs to be a defined behavior for what should happen here.

The good thing about  is that it usually works more often.
This is basically because most plug-ins that require a src don't
recognize the data param of  and browsers have to jump through
hoops to invent a src param when using  to make those nasty
plug-ins work.  Plug-in developers need to shape up.

To add, 's codebase attribute is most of the time misused.
It's supposed to be a basehref for the data and classid attributes (or
in the case of java, the directory where the class files are at).
However, IE-goers use the codebase to specify URIs to cab files.  This
means that 'codebase' has to be ignored if it has junk in it like a
uri to a .cab file.

As for Firefox not ignoring the classid when it sees
classid="clsid:", that's a problem. Firefox should ignore it and use
the data attribute. Of course Firefox *can* (with a plug-in) support
activeX methods for the Windows Media Plug-in. In these situations,
Firefox should honor the classid, but only for ones that it supports.
This needs to be spelled out clearly so that the Firefox devs are
officially allowed to favor the data attribute.

On a side note, I always wanted to do this:

If the jre throws an error you see this and not an applet displaying
that there was an error.


Fallback mechanisms don't currently work for java.  Alternate content
for java is like the  tag where it only works if java isn't
supported (because you have it off or not installed.). Plus java can't
really make use of the data attribute. Browsers currently don't
support it that way anyway, but it'd be nice.  Something to think
about at the least.

As for plug-in developers, I'd like to see, "Our plug-in is HTML4 and
or HTML5 compliant. Our plug-in can be loaded via the embed element or
the object element without browsers having to map parameters around.".
If we could get the major plug-in developers to conform, that'd be
great.

There are plenty of things that need to be cleared up.

--
burnout426

Re: [whatwg] Handling of script elements inside rendered OBJECT

[Shadow2531]

On 5/11/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:

Shadow2531 wrote:
> 
>alert('You should not see this!');
> 
>
> What should happen in situations like that?
>
> The script element is alternate content.
> The object is rendered.
> The script SHOULD NOT be executed *until* the alernate content is
> rendered.

If scripts inside  aren't executed, then consider what should
happen with this:


   document.write("<object type=\"text/html\" data=\"test\">");

alternate content for when both scripts and the object isn't
supported

   document.write("<\/object>");


Because of the way document.write() works by writing data back into the
stream, the question is: if scripts inside objects are not executed, is
the second script considered part of the alternate content and thus not
executed?
Lachlan Hunt
http://lachy.id.au/



Ouch. I see your point.

That problem could be avoided by authors making sure each
document.write() wrote complete element markup instead of splitting it
up like in your example. However, your example is far too common and
unless I'm missing something, not executing scripts in object tags
would break lots of things. Ouch.

While we're at it though, can you think of other reasons?

Thanks

--
burnout426

[whatwg] Handling of script elements inside rendered OBJECT

[Shadow2531]

  alert('You should not see this!');


What should happen in situations like that?

The script element is alternate content.
The object is rendered.
The script SHOULD NOT be executed *until* the alernate content is
rendered. (For example, if it's an image, you switch images off and
the alternate content is rendered.)

It makes sense to NOT execute the script in this situation.

However, browsers currently execute the script. (IE6 does not, but
that may be quirky object tag handling.)

--
burnout426

[whatwg] Handling of script elements inside rendered OBJECT

[Shadow2531]

   alert('You should not see this!');


What should happen in situations like that?

The script element is alternate content.
The object is rendered.
The script SHOULD NOT be executed *until* the alernate content is
rendered. (For example, if it's an image, you switch images off and
the alternate content is rendered.)

It makes sense to NOT execute the script in this situation.

However, browsers currently execute the script. (IE6 does not, but
that may be quirky object tag handling.)

--
burnout426

Re: [whatwg] getElementsByClassName()

[Shadow2531]

On 2/15/06, Ric Hardacre <[EMAIL PROTECTED]> wrote:
>
>
> Shadow2531 wrote:
> >
> > I was *messing* around with 2 different *examples*.
> >
> > 1.) http://shadow2531.com/opera/js/getElementsByClassName/000.html
> >
> > That one supports:
> > getElementsByClassName(string);
> > getElementsByClassName(array);
> >
> > If the string has spaces in it, it's considered that nothing will
> > match and returns null.
> > If it's an array, all must be present for an element to match.
> >
> > 2.) http://shadow2531.com/opera/js/getElementsByClassName/001.html
> >
> > Now this one supports the same 2 types, but the string handling is
> > different. The string is space-separated.
> >
> > So, with this second example, you can do:
> >
> > document.getElementsByClassName("aaa");
> > document.getElementsByClassName(["bbb", "ccc"]);
> > document.getElementsByClassName("bbb ccc");
> >
> > (The second 2 produce the same result. The 3rd one might just be
> > cleaner in certain situations)
> >
> > I'm liking what options the second example provides. (not necessarily
> > the code as I just threw it together and didn't think about
> > exceptions, optimization and code size. Plus I just used a global
> > function for the example.)
> >
> > Do you agree with the string being space-separated?
> > It seems to make sense at least for html where a classname can't have 
> > spaces.
>
> looks good to me, the only quirk of this would be that you cant choose
> class="foo bar" specifically over class="foo" with gebcn("foo bar") but
> if this is the stated behaviour then i guess that's ok.

gebcn("foo bar") should match any element that has *both* "foo" and
"bar", but *not necessarily just* "foo" and "bar".

If the element doesn't have both foo and bar, the element doesn't
match. Therefore, gebcn("foo bar") wouldn't match class="foo" because
"bar" is not present. None of the methods of searching in my examples
will work as a getElementsByClassAttributeValue. I don't think gebcn
is supposed to do that anyway.

> on a side note, it might also be worth stating that in this case
> gebcn("foo bar") should only return the class="foo bar" element once,
> not twice (one instance for "foo" and one instance for "bar"). just for
> completeness

Correct, each element should only be evaluated once and if just one
class you search for in the element's class attribute is not present,
the element does not match and it moves on to the next element.

That was the idea at least., but maybe my examples don't fully do what
I meant or were you just clarifying? :)

--
Shadow2531

Re: [whatwg] getElementsByClassName()

[Shadow2531]

On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Shadow2531 wrote:
> > O.K.  Then, it should be getElementByClassName*s*() where you have
> > have 1 or more classname arguments.  If you pass more than 1 class
> > name, both class names have to be present in the classname attribute
> > for the element to match.
>
> This seems like a sensible change. Call it getElementsByClassNames()
> would make it obvious that if you supply multiple class names, you get
> only elements with all those names. And it would be a reasonably obvious
> reduction that if you just supply a single name, you would get all
> elements which had that one class name.
>
> So we've ended up with:
>
> elem.getElementsByClassNames("foo");
> and
>
> elem.getElementsByClassNames(["foo", "bar"]);
> or
> elem.getElementsByClassNames("foo", "bar");
> or both.
>
> Are there similar functions in the DOM at the moment which can take
> multiple arguments? Do you pass an array or multiple individual
> arguments, or can you do both?
>
> Gerv
>

I was *messing* around with 2 different *examples*.

1.) http://shadow2531.com/opera/js/getElementsByClassName/000.html

That one supports:
getElementsByClassName(string);
getElementsByClassName(array);

If the string has spaces in it, it's considered that nothing will
match and returns null.
If it's an array, all must be present for an element to match.

2.) http://shadow2531.com/opera/js/getElementsByClassName/001.html

Now this one supports the same 2 types, but the string handling is
different. The string is space-separated.

So, with this second example, you can do:

document.getElementsByClassName("aaa");
document.getElementsByClassName(["bbb", "ccc"]);
document.getElementsByClassName("bbb ccc");

(The second 2 produce the same result. The 3rd one might just be
cleaner in certain situations)

I'm liking what options the second example provides. (not necessarily
the code as I just threw it together and didn't think about
exceptions, optimization and code size. Plus I just used a global
function for the example.)

Do you agree with the string being space-separated?
It seems to make sense at least for html where a classname can't have spaces.

--
Shadow2531

Re: [whatwg] getElementsByClassName()

[Shadow2531]

On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> This seems like a sensible change. Call it getElementsByClassNames()
> would make it obvious that if you supply multiple class names, you get
> only elements with all those names. And it would be a reasonably obvious
> reduction that if you just supply a single name, you would get all
> elements which had that one class name.
>
> So we've ended up with:
>
> elem.getElementsByClassNames("foo");
> and
>
> elem.getElementsByClassNames(["foo", "bar"]);
> or
> elem.getElementsByClassNames("foo", "bar");
> or both.

O.K.

> Are there similar functions in the DOM at the moment which can take
> multiple arguments? Do you pass an array or multiple individual
> arguments, or can you do both?

For getElementsByClassNames( var )
var could be an object or a string.  The function could use typeof to
check which one it is. If it's an object, the function could check its
elements to make sure they are strings. So, you could pass a list or a
string.

For getElementsByClassNames("string1", "string2", "string3",
"stringN"), the function has an 'arguments' array that will output
"string1,string2,string3,stringN".

So, it should be possible to support, passing 1 or more strings, or 1
or more arrays, or a mixture. We don't want to go crazy though.

I'd prefer to just be able to pass one or more strings and keep it at
that. However, if you had an array of strings, you'd then be forced to
build a call to getElementsByClassNames() via eval() or use some other
method.

Do we need to be able to pass an array of arbitrary classnames?

burnout426

Re: [whatwg] getElementsByClassName()

[Shadow2531]

On 2/3/06, Shadow2531 <[EMAIL PROTECTED]> wrote:
> O.K.  Then, it should be getElementByClassName*s*() where you have
> have 1 or more classname arguments.  If you pass more than 1 class
> name, both class names have to be present in the classname attribute
> for the element to match.

I just to be clear.  If you do getElementByClassName("this", "that",
"other"), should that only match elements that have all those in their
class attribute value or does it match any element that has "this" and
any element that has "that" and any element that has "other"?

I just want to be sure on the intended behavior.

burnout426

Re: [whatwg] getElementsByClassName()

[Shadow2531]

On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Shadow2531 wrote:
> > I just threw them together as a proof of concept, but I have no doubt
> > that the class attribute value should be a space separated list of
> > classnames and the getElementByClassName function should split up the
> > class attribute value into an array and then search for the class name
> > to see if there's a match (Or use regex to be simpler). I also added a
> > case insensitve search option.
>
> IMO there should be no option; if class names are defined as
> case-insensitive, we should search case-insensitively, and if they
> aren't, we shouldn't.

O.K. agreed.

> > As the case above, getElementByClassName("foo bar") doesn't make sense
> > to me because there are 2 class names in there and it's
> > getElementByClassName, not getElementsByClassName*s*().
> >
> > In getElementByClassName("foo bar") , "foo bar" should be normalized
> > "foo" and therefore match all 3 because they all have "foo" in the
> > class attribute value.
>
> I think this behaviour would violate the rule of least surprise. Better
> behaviour would be to match nothing, treating "foo bar" as a single
> class name. Rationale: just because HTML doesn't allow class names with
> spaces doesn't mean no other languages do, and the coding error would be
> much easier to spot (you'd get no elements at all).

Point taken.  That would be fine.  I think I now agree with you about
not normalizing an argument with spaces.

> > getElementsByClassName*s*() should be a separate function and I agree,
> > getElementsByClassNames*s*("foo", "bar") would be great if possible.
>
> I also think it's not ideal to have two functions with such similar names.

O.K.  Then, it should be getElementByClassName*s*() where you have
have 1 or more classname arguments.  If you pass more than 1 class
name, both class names have to be present in the classname attribute
for the element to match.

I'm just being picky here though, but getElementByClassName() implies
only one classname where as getElementByClassNames() implies one or
more. Although as long as you know what the function does, that hardly
matters, but I bring it up anyway. :)

burnout426

Re: [whatwg] getElementsByClassName()

[Shadow2531]

On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Musing...
>
> If you have:
>
> Fred
> Barney
> Wilma
>
> which should be picked up by getElementsByClassName("foo bar")?
>
> In the "string split" mode, it would pick up all three. However, I
> suggest that designers might be misled by this interface into thinking
> that it only picks up the first one - which matches exactly.
>
> So I think a multiple-argument interface would remove this possible
> confusion, and make things more obvious than a whitespace-splitting
> interface.
>
> getElementsByClassName("foo", "bar") ideally, but if that's hard, then
> getElementsByClassName(["foo", "bar"]);
>
> So I agree with Brad, I think :-)
>
> Gerv
>

In  I wrote
2 prototypes for Opera and Firefox: getElementsByClassName()

and getElementsByClassNameNS()
.

I just threw them together as a proof of concept, but I have no doubt
that the class attribute value should be a space separated list of
classnames and the getElementByClassName function should split up the
class attribute value into an array and then search for the class name
to see if there's a match (Or use regex to be simpler). I also added a
case insensitve search option.

As the case above, getElementByClassName("foo bar") doesn't make sense
to me because there are 2 class names in there and it's
getElementByClassName, not getElementsByClassName*s*().

In getElementByClassName("foo bar") , "foo bar" should be normalized
"foo" and therefore match all 3 because they all have "foo" in the
class attribute value.

getElementsByClassName*s*() should be a separate function and I agree,
getElementsByClassNames*s*("foo", "bar") would be great if possible.

Just my thoughts,

burnout426

Re: [whatwg] embedded content: OBJECT

[Shadow2531]

I too think there needs to be some specifics on how the UA should
handle objects.

The current methods of "The server Content-Type rules all" and "If
there's no data attribute, then fail" are
not working out. There are cases where a data attribute is not needed
and there are cases where a type attribute
should be the priority. The type attribute is really used as "Here's
what plug-in/handler I want to use".

There also needs to be some specifics for the classid attribute.  If
the classid contains an unsupported naming
scheme, should the UA really have to just fail or should it go on and
try to use the type and data attributes?

How should data uris be handled?  Is it just up to the plug-in to
handle the passed data uri or is the UA allowed
to create a file from the data URI and pass the file path to the
plug-in/hander (if it can do it safely)?

What should happen when a UA encounters a codebase attribute that has
a path to a cab file instead of a base URI?
Should the UA always use the codebase to resolve URIs even if it has junk in it?

Anyway, here's how ( which still isn't specific enough ) I think a UA
should handle the object element.


Object Element - Order of Operations:

Pre-Initialization:

First, the UA should check for a classid attribute.

If present and the the UA has a handler associated with the specified
naming scheme, then the UA should pass all arguments to the handler in
a manner that is specific to the handler.

If the classid attribute is not present or the naming scheme is not
supported or the handler returns an error code, then the UA must check
for the presence of a type attribute.

If it exists, the UA must check to see if it has a handler associated
with the Content-Type specified in the type attribute.

If the Content-Type is associated with a handler, the UA must pass all
arguments to the handler.

If that fails and there is a data attribute, check the Content-Type
sent by the server for the file and determine if there's a handler
associated with the type.

If there is a handler associated with the type, pass all arguments to
the handler.

If there is not, the UA *should* compare the file extension to a list
of known Content-Types associated with that extension.

If a handler is found, pass all arguments to the handler.

If no handler was found through any of the methods, display the
fallback content.

( URIs to files should be passed to the handler and the handler should
download the files as necessary. The Ua should
not download the file on its own. Only the handler should make that
request to the UA.)


Initialization:

Once the handler gets the arguments, it *must* detmermine whether it
has the necessary and valid arguments to initialize. If it does not,
it should return a failure code. If it does, it should try to
initialize and if successful, return a success code; otherwise, return
a failure code. The handler should return a failure code in every
situation where there's no need to initialize in the first place.

The UA must check for this return code to determine whether to display
fallback content.


Anyway, current plug-ins do not conform to html4's recommendations and
it's a problem. However, there are more situations out there
there than the spec covers.  The current way of just following what
html4 recommends doesn't work. (An example of this would
be Firefox choking on classid value that it doesn't support instead of
ignoring it.)

I don't know the internals of how a plug-in is initialized etc.

This is just to show the need for specifics and to spark up some discussion.

burnout426