From whatwg at cycloid.f9.co.uk  Fri Sep  1 04:12:22 2006
From: whatwg at cycloid.f9.co.uk (Ric Hardacre)
Date: Fri, 01 Sep 2006 12:12:22 +0100
Subject: [whatwg] Scoped tabindex proposal
In-Reply-To: <004601c6cd5d$8fdd1080$3401a8c0@TERRA>
References: <BAY109-F6D3BB4EDC639EDA13E7C7B43F0@phx.gbl>
	<004601c6cd5d$8fdd1080$3401a8c0@TERRA>
Message-ID: <44F81596.50301@cycloid.f9.co.uk>



Andrew Fedoniouk wrote:
> 
> It is better to use another attribute for that, say - tabgroup.
> It should accept exactly the same set of values as tabindex.
> 
> <input tabindex="1" />
> <foo tabgroup="2">
>    <input tabindex="1" />
>    <input tabindex="2" />
> </foo>
> <input tabindex="3" />
> 
> The order of tab traversal of inputs will be in this case as
> their natural order (in this case).
> 
> tabgroup marked element may or may not have tabindex
> defined - so it can be focusable by itself.
> If both tabgroup and tabindex are defined and have numeric values then
> tabindex value is used as an index.
> 
> So it will be possible to say:
> <foo tabindex="2" tabgroup >
> 
> Andrew Fedoniouk.
> http://terrainformatica.com
> 
> 

how about allowing decimals, where by default "1" implies "1.0"? :

 <input tabindex="1" />
 <foo tabindex="2">
    <input tabindex="2.1" />
    <input tabindex="2.2" />
 </foo>
 <input tabindex="3" />

This also allows you to quickly associate the grouping of an input by
it's value when viewing the source:

<table>
<tr>
   <td><input tabindex="1.1" /></td>
   <td><input tabindex="2.1" /></td>
</tr>
<tr>
   <td><input tabindex="1.2" /></td>
   <td><input tabindex="2.2" /></td>
</tr>
<tr>
   <td></td>
   <td><button tabindex="3" /></td>
</tr>
</table>

obviously the above example could have just used tabindex 1 through 5
but you get the point

Ric Hardacre
http://www.cyclomedia.co.uk/




From zcorpan at hotmail.com  Fri Sep  1 04:57:30 2006
From: zcorpan at hotmail.com (Simon Pieters)
Date: Fri, 01 Sep 2006 11:57:30 +0000
Subject: [whatwg] Scoped tabindex proposal
In-Reply-To: <44F81596.50301@cycloid.f9.co.uk>
Message-ID: <BAY109-F348130203D37B2D2C1DA98B43C0@phx.gbl>

Hi,

From: Ric Hardacre <whatwg at cycloid.f9.co.uk>
>how about allowing decimals, where by default "1" implies "1.0"? :
>
>[...]
>
>This also allows you to quickly associate the grouping of an input by
>it's value when viewing the source:

You can already do that; just use tabindex 11, 21, 12, 22 and 30.

Regards,
Simon Pieters




From aaronlev at moonset.net  Fri Sep  1 07:00:37 2006
From: aaronlev at moonset.net (Aaron Leventhal)
Date: Fri, 01 Sep 2006 10:00:37 -0400
Subject: [whatwg] Scoped tabindex proposal
In-Reply-To: <BAY109-F6D3BB4EDC639EDA13E7C7B43F0@phx.gbl>
References: <BAY109-F6D3BB4EDC639EDA13E7C7B43F0@phx.gbl>
Message-ID: <44F83D05.0@moonset.net>

tabindex="-1" doesn't just remove items from the tab order. It also 
makes items focusable via mouse click or script, which is important when 
designing custom container widgets like spreadsheets, etc. via 
Javascript. In fact any negative value does it.

Don't try to overload the tabindex attribute. First, the browsers 
currently optimize it knowing that it's an integer. Second, the scoping 
is orthogonal. Third, magic values are less readable. It's voodoo.

- Aaron



Simon Pieters wrote:
> Hi,
>
> Currently if you want to use the tabindex to change the tab order you 
> mostly have to specify tabindex on all links and form controls prior 
> to the area you want to modify the tab order, because otherwise that 
> area would be before all prior elements in the tab order, which in 
> most cases isn't wanted. Therefore there's a need to scope tabindex 
> somehow.
>
> So here's an idea. A new value for the tabindex attribute, "scoped". 
> Here's an example:
>
>   <p>The following links should be focused in the order which the link 
> text indicates:
>   <p><a href="#">first</a>
>   <table tabindex="scoped">
>    <tr>
>     <td><a href="#" tabindex="1">second</a>
>     <td><a href="#" tabindex="3">forth</a>
>    <tr>
>     <td><a href="#" tabindex="2">third</a>
>     <td><a href="#" tabindex="4">fifth</a>
>   </table>
>   <p><a href="#">last</a>
>
> The table itself is not in the tab order and is not focusable.
>
> I'm not sure if we need another attribute or something for this 
> instead as .tabIndex is a long and not a DOMString. Or perhaps we 
> could say that all elements that have a tabindex attribute is a 
> scoping element, so that authors can use tabindex="-1" on the table 
> instead.
>
> Here's a pointer of where this (or something similar) is called for:
>
>   http://accessifyforum.com/viewtopic.php?t=6034
>
> Regards,
> Simon Pieters
>
>
>


From bfults at gmail.com  Fri Sep  1 10:43:09 2006
From: bfults at gmail.com (Brad Fults)
Date: Fri, 1 Sep 2006 10:43:09 -0700
Subject: [whatwg] Scoped tabindex proposal
In-Reply-To: <44F83D05.0@moonset.net>
References: <BAY109-F6D3BB4EDC639EDA13E7C7B43F0@phx.gbl>
	<44F83D05.0@moonset.net>
Message-ID: <1959130b0609011043x46eb2e7amf248490a053b3226@mail.gmail.com>

On 9/1/06, Aaron Leventhal <aaronlev at moonset.net> wrote:
> Don't try to overload the tabindex attribute. First, the browsers
> currently optimize it knowing that it's an integer. Second, the scoping
> is orthogonal. Third, magic values are less readable. It's voodoo.

Yes, yes, and yes. Completely agreed.

-- 
Brad Fults


From akusaya at gmx.net  Fri Sep  1 19:49:13 2006
From: akusaya at gmx.net (akusaya at gmx.net)
Date: Sat, 2 Sep 2006 10:49:13 +0800
Subject: [whatwg] Server-sent events or Server-sent DOM events?
Message-ID: <165276294.20060902104913@gmx.net>

Since Opera made a demo of the above technology, I want to publicize
it more. But I'm confused as what term is more suitable. There are two
mention of this technology in
http://whatwg.org/specs/web-apps/current-work/

In Abstract section,

"This specification introduces features to HTML and the DOM that ease
the authoring of Web-based applications. Additions include the context
menus, a direct-mode graphics canvas, inline popup windows, and
*server-sent events*."

But in Section 7.1,

7.1. [SCS] *Server-sent DOM events*

Which one is the correct term for that?

Or is Server-sent DOM events a more specific name for Server-sent
events?

Thank you.



From cbiesinger at web.de  Fri Sep  1 19:49:07 2006
From: cbiesinger at web.de (Christian Biesinger)
Date: Fri, 01 Sep 2006 19:49:07 -0700
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>
References: <44E68AA7.8080008@web.de>	
	<6b9c91b20608191008oc274b9dq39cc6f9aa025d8c1@mail.gmail.com>	
	<44E932EC.1020507@mit.edu>	
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>	
	<44EA1A02.4090207@mit.edu>
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>
Message-ID: <44F8F123.9010603@web.de>

Sorry for replying to this a bit late, but other stuff kept me 
distracted the last two weeks...

I should maybe also note that the purpose of the question wasn't so much 
to introduce new attributes to embed with (maybe) nicer semantics, but 
more about how to implement <embed> as it exists today in a web browser, 
Gecko in this case.

I should maybe also note that in Gecko, if you specify a type attribute 
the plugin will always be invoked, no matter what the content of the src 
attribute (indeed even if there is no src attribute), and also 
independent of what the server sends. (This is different from <object>, 
where on Gecko trunk the server-sent type always wins)

I also want to note that generally in HTML the type attributes are 
purely advisory and the server's type takes precedence, so I'm not 
really in favour of failing if the types don't match...

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 <object><embed></object> way really :)

> <object fallondata="true" codetype="type"  classid="clsid:123456"
> type="type" data="file.ext">
> <param name="src" value="file.ext">
> </object>
> 
> could be an answer to this.

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

> 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 <object> 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...

> 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?

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

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

<param> elements are only handled by the plugin itself...

-christian


From shadow2531 at gmail.com  Fri Sep  1 22:49:27 2006
From: shadow2531 at gmail.com (Shadow2531)
Date: Sat, 2 Sep 2006 01:49:27 -0400
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <44F8F123.9010603@web.de>
References: <44E68AA7.8080008@web.de>
	<6b9c91b20608191008oc274b9dq39cc6f9aa025d8c1@mail.gmail.com>
	<44E932EC.1020507@mit.edu>
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>
	<44EA1A02.4090207@mit.edu>
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>
	<44F8F123.9010603@web.de>
Message-ID: <6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>

On 9/1/06, Christian Biesinger <cbiesinger at web.de> 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 <object><embed></object> way really :)

:) Yeh, it's not THAT bad.

> > <object fallondata="true" codetype="type"  classid="clsid:123456"
> > type="type" data="file.ext">
> > <param name="src" value="file.ext">
> > </object>
> >
> > 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 <object> 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:

<object codebase="http://somesite.com/dir/">
    <param name="baseurl" "http://someothersite.com/">
</object>

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:

<param name="autostart" value="false">

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


From zcorpan at hotmail.com  Sat Sep  2 09:17:47 2006
From: zcorpan at hotmail.com (Simon Pieters)
Date: Sat, 02 Sep 2006 16:17:47 +0000
Subject: [whatwg] Scoped tabindex proposal
In-Reply-To: <44F83D05.0@moonset.net>
Message-ID: <BAY109-F156EDC848DE0D0E398C227B43D0@phx.gbl>

Hi,

From: Aaron Leventhal <aaronlev at moonset.net>
>tabindex="-1" doesn't just remove items from the tab order. It also makes 
>items focusable via mouse click or script, which is important when 
>designing custom container widgets like spreadsheets, etc. via Javascript. 
>In fact any negative value does it.

Indeed.

>Don't try to overload the tabindex attribute.

tabindex="scoped" is overloading indeed, but changing the tab order 
algorithm isn't really overloading the tabindex attribute (if we would say 
that all tabindex elements are scoping elements).

>First, the browsers currently optimize it knowing that it's an integer.

I agree that tabindex should still be a long (and not DOMString).

>Second, the scoping is orthogonal.

Then it would be better to have a separate attribute. That also allows the 
use of the current tab order for nested tabindex elements, and the ability 
to declare unfocusable scoping elements.

>Third, magic values are less readable. It's voodoo.

Ok.

Regards,
Simon Pieters




From anders.rundgren at telia.com  Sun Sep  3 00:31:37 2006
From: anders.rundgren at telia.com (Anders Rundgren)
Date: Sun, 3 Sep 2006 09:31:37 +0200
Subject: [whatwg] Modal Dialog Box support
Message-ID: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>

I know that this issue is a bit touchy among web purists but the fact is
that the world is going from surfing to applications.  The "wet dream" is
actually to get the same functionality in the browser like in a "fat client".

But it is very hard to create certain types of applications without having
modal dialogs.  AFAIK the existing alert() box is already modal (at least
in MSIE) so modality is well established.

That modal dialogs like featured in MSIE are not that much used
is because there is no similar function in other browsers.  You can
to some extent  "simulate" modality in Firefox but this simulation is
[of course...] not supported by MSIE.

The argument that tabbed browsing is incompatible with modality is
something I don't buy into, it is an implementation issue.  Exactly the
same issues should apply to alert() BTW.

Although AJAX may be great, it does in no way replace the need for
having modal "transaction points".

The net effect of ignoring legitimate needs of "legacy" app developers is
forcing them into using a single browser, possibly also using non-web
extensions like XAML.   I think this consideration is more important than
if a feature is absolutely "right" or "wrong". 

Sincerely
Anders Rundgren



From anders.rundgren at telia.com  Sun Sep  3 00:47:07 2006
From: anders.rundgren at telia.com (Anders Rundgren)
Date: Sun, 3 Sep 2006 09:47:07 +0200
Subject: [whatwg] Browser Signature Standards Proposal
Message-ID: <01cd01c6cf2d$28710010$82c5a8c0@arport2v>

F.Y.I.

I'm sorry about WASP, I was not aware of your activities when I created
the Web Activated Signature Protocol.

Background:
http://middleware.internet2.edu/pki06/proceedings/rundgren-websigning.ppt

Minimal technical description:
http://webpki.org/WASP-tutorial.pdf

The works:
http://webpki.org/WASP-specifications-2006-08-26.zip

There is [much] more if somebody is interested.

Anders Rundgren





From dveditz at cruzio.com  Mon Sep  4 09:27:39 2006
From: dveditz at cruzio.com (Daniel Veditz)
Date: Mon, 04 Sep 2006 09:27:39 -0700
Subject: [whatwg] Persistent storage is critically flawed.
In-Reply-To: <Pine.LNX.4.62.0608282350000.10139@dhalsim.dreamhost.com>
References: <44F18BE5.2040103@arc.net.au>	<403d38e20608272109v278a0e76q52cba55a60ffce42@mail.gmail.com>	<44F28679.6030200@arc.net.au>	<851c8d310608280127x9d18878n4a4b1ca4e36eabd9@mail.gmail.com>	<6c97b8b10608280431w55960cf3s887703c57dc5024b@mail.gmail.com>
	<Pine.LNX.4.62.0608282350000.10139@dhalsim.dreamhost.com>
Message-ID: <44FC53FB.1040301@cruzio.com>

Ian Hickson wrote:
> Note that the problems you raise also exist (and have long existed) with 
> cookies; at least the storage APIs default to a safe state in the general 
> case instead of defaulting to an unsafe state.

In what way do the storage API's default to a "safe state"? What "unsafe
state" is the alternative? You've lost me.

Compared to cookies storage seems less safe: the default cookie access
is to the setting host only, a case that does not even exist with global
storage. To publish a cookie to a wider family of hosts the setting host
must explicitly set a domain on the cookie. (Ditto path, but that turns
out to be illusory protection due to the DOM same-origin policy).

Web-app developers aren't complaining they can't read cookies they need
from sub-domains, they're complaining when private cookies leak or when
they're fooled by a cookie injected at a higher domain (e.g. .co.uk
cookies).

Let me throw out two alternatives for providing "private" persistent
storage, neither of which complicates the API (though may complicate the
implementation).

The first piggy-backs on the domain vs host cookie concept as applied to
entire storage objects. Each host would have a private persistent
storage object that could only be accessed by that host; shared objects
would need to be explicitly named. There should be a difference in how
the two types are named
  a) using the cookie domain nomenclature to indicate the similar
  concepts "www.foo.com" could represent the host storage only
  accessible to that host, and a leading '.' in ".www.foo.com"
  would represent a shared storage area. You could argue that
  people will forget the dot as they do with cookie domains,
  but they only do with cookies because UA's let them get away
  with it.
  b) another choice would be to make globalStorage[''] magic and
  mean the private storage for the current host. No one is going
  to implement universally accessible storage (the spec even
  recommends against it), you could just take that out of the spec
  and reuse it for this. All other named areas would be shared
  as described by the spec.

The second alternative would be to have private and shared storage items
within a single storage area. I know you weren't keen on adding another
attribute like "secure", what if instead there was a convention such as
"keys which start with an underscore are private and can only be
accessed if the current host matches the storage area domain".

My personal preference is for 1b -- use globalStorage[''] as the
non-shared storage area.

-Dan Veditz




From webmaster at keryx.se  Mon Sep  4 10:37:30 2006
From: webmaster at keryx.se (Keryx webb)
Date: Mon, 04 Sep 2006 19:37:30 +0200
Subject: [whatwg] href on any element
In-Reply-To: <op.te14t6uc4suneb@g5.local>
References: <002401c6cb84$83a07350$0500a8c0@computername>
	<op.te14t6uc4suneb@g5.local>
Message-ID: <44FC645A.405@keryx.se>

Sorry for starting a thread and then being away for quite a while. I've been 
exceptionally busy!

Let's clarify some of my wishes:

Do I wish that the href-attribute is available on exactly *every* element? No, 
but on many *more* than today.

A. I do find myself writing a lot of:
<abbr title="foobar"><a href="foo">bar</a></abbr>
<dfn><a href="foo">bar</a></dfn>
<em><a href="foo">bar</a></em>


B. I also find myself writing large amounts of:
<ul>
<li><a href="page1">Menuitem 1</a></li>
<li><a href="page2">Menuitem 2</a></li>
</ul>

To make the whole LI-element clickable I have to resort to CSS
( ul#nav li a { display: block } ) which does not work in all browsers or 
JavaScript, which also is a hassle.

Why would it be better to loose the a-tags?
- Code-reduction is always a good thing! (The XLink solution means a lot of
   code => no reduction.)
- Convenience for hand-coders, whose work often make it into CMS-templates.

Will it break backwards compatibility? Yes, if todays browsers are supposed to 
be able to render WHATWG-pages. But there are lots of other things in WHATWG 
that they do not understand either. It's only the very latest browsers that can 
handle canvas. No browser fully implements Web Forms 2.0 (as far as I know).

Please point me to a document if I've got this wrong - I am after all a newbie 
on this list - but adding href on more elements is not *changing* todays HTML, 
but *adding* to it. Isn't that what HTML 5 is all about.

And how much it may be disliked by browser vendors, I still think they do intend 
to support XHTML 2.0, and need to prepare for a day when href is available on 
*most* elements, anyway.

Actually, if one dislikes XHTML 2.0, implementing its one "killer feature" in 
HTML 5 would make sense as well. Who would want to use XHTML 2.0 if it does not 
offer any significant advantage?

As Molly H writes:
"All I really, really want from XHTML 2.0 is href to be available for any 
element." (I'd like to change that to "many more elements than today") 
http://www.molly.com/2006/08/14/angry-not-zeldman-meyer-and-fair-concerns-about-the-w3c/



Lars Gunther



From cbiesinger at web.de  Mon Sep  4 15:49:56 2006
From: cbiesinger at web.de (Christian Biesinger)
Date: Mon, 04 Sep 2006 15:49:56 -0700
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>
References: <44E68AA7.8080008@web.de>	
	<6b9c91b20608191008oc274b9dq39cc6f9aa025d8c1@mail.gmail.com>	
	<44E932EC.1020507@mit.edu>	
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>	
	<44EA1A02.4090207@mit.edu>	
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>	
	<44F8F123.9010603@web.de>
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>
Message-ID: <44FCAD94.2050704@web.de>

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".

> 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 <object>), but that's all. It 
certainly doesn't map codebase to anything else.

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

Yes, that would be good. Although perhaps WhatWG is the wrong spec for 
this, since it won't describe a plugin API...

> As for the priority deal. Here's an example:
> 
> <object codebase="http://somesite.com/dir/">
>    <param name="baseurl" "http://someothersite.com/">
> </object>

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).

> 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.

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...

-christian



From christoph.paeper at crissov.de  Tue Sep  5 01:39:33 2006
From: christoph.paeper at crissov.de (=?ISO-8859-1?Q?Christoph_P=E4per?=)
Date: Tue, 5 Sep 2006 10:39:33 +0200
Subject: [whatwg] return lowercase hex values for fillStyle and
	strokeStyle
In-Reply-To: <op.te2afeqjaw9dld@id-c0020.oslo.opera.com>
References: <op.te2afeqjaw9dld@id-c0020.oslo.opera.com>
Message-ID: <2AADA27A-0DFA-46EC-B384-7754DF5FBDBB@crissov.de>

*Anne van Kesteren*:
> Instead of returning an uppercase six digit hex value I suggest  
> returning a lowercase value for compatibility with what UAs  
> (including IE) currently do

It may be the right decision on compatibility grounds, but other than  
that lowercase hexadecimal digits (0-9, a-f) are almost always a bad  
choice, because a, c and e have no ascenders like every hindu-arabic  
decimal digit has and thus make the number harder to read. This  
obviously does not apply to fonts with old-style numerals aka. text  
figures, where 0, 1 and 2 have neither ascenders (like 6 and 8) nor  
descenders (like 3, 4, 5, 7 and 9), but those are rather unlikely to  
be used in a programming environment.


From christoph.paeper at crissov.de  Tue Sep  5 02:01:38 2006
From: christoph.paeper at crissov.de (=?ISO-8859-1?Q?Christoph_P=E4per?=)
Date: Tue, 5 Sep 2006 11:01:38 +0200
Subject: [whatwg] Modal Dialog Box support
In-Reply-To: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>
Message-ID: <BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>

*Anders Rundgren*:
> But it is very hard to create certain types of applications without  
> having
> modal dialogs.

That does not mean modal dialogs were a good idea, ever.



From anders.rundgren at telia.com  Tue Sep  5 02:30:23 2006
From: anders.rundgren at telia.com (Anders Rundgren)
Date: Tue, 5 Sep 2006 11:30:23 +0200
Subject: [whatwg] Modal Dialog Box support
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>
	<BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>
Message-ID: <005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>

>> But it is very hard to create certain types of applications without  
>> having  modal dialogs.

>That does not mean modal dialogs were a good idea, ever.

Christoph,

You are free to not use modal dialog in *your* applications.

You are also free to support end-users when windows magically "disappear"
because the [stupid] user in some way activated the wrong window.

You are also free to write the booklet "Dialogs for dummies", where you describe
for the world of legacy software developers why the concept of a transaction point
which is a core facility in a database system, should not have a GUI counterpart.

However, I would be less pleased if such ideas become the basis for standards
development because that without doubt leads to fragmentation, since not all
vendors can afford a "von oben/besserwisser" attitude towards their customers.

I once started out myself with the idea of bringing "perfect" solutions to the market.
Unfortunately, what was probably perfect for some people turned out as useless
for another group :-(

thanx,
Anders R



From rimantas at gmail.com  Tue Sep  5 02:46:35 2006
From: rimantas at gmail.com (Rimantas Liubertas)
Date: Tue, 5 Sep 2006 12:46:35 +0300
Subject: [whatwg] Modal Dialog Box support
In-Reply-To: <005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>
	<BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>
	<005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>
Message-ID: <5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com>

<...>
> You are also free to write the booklet "Dialogs for dummies", where you describe
> for the world of legacy software developers why the concept of a transaction point
> which is a core facility in a database system, should not have a GUI counterpart.
<...>

Chapter 30 "Using Dialogs" in "About the Face 2.0" [1] by Alan Cooper
makes a good
read too.

[1] http://www.amazon.com/About-Face-2-0-Essentials-Interaction/dp/0764526413/sr=8-1/qid=1157449548/ref=pd_bbs_1/102-1456987-0371351?ie=UTF8&s=books

Regards,
Rimantas
--
http://rimantas.com/


From chaals at opera.com  Tue Sep  5 04:54:10 2006
From: chaals at opera.com (Charles McCathieNevile)
Date: Tue, 05 Sep 2006 13:54:10 +0200
Subject: [whatwg] return lowercase hex values for fillStyle and
	strokeStyle
In-Reply-To: <2AADA27A-0DFA-46EC-B384-7754DF5FBDBB@crissov.de>
References: <op.te2afeqjaw9dld@id-c0020.oslo.opera.com>
	<2AADA27A-0DFA-46EC-B384-7754DF5FBDBB@crissov.de>
Message-ID: <op.tfel0kciwxe0ny@widsith.local>

On Tue, 05 Sep 2006 10:39:33 +0200, Christoph P?per  
<christoph.paeper at crissov.de> wrote:

> *Anne van Kesteren*:
>> Instead of returning an uppercase six digit hex value I suggest  
>> returning a lowercase value for compatibility with what UAs (including  
>> IE) currently do
>
> It may be the right decision on compatibility grounds, but other than  
> that lowercase hexadecimal digits (0-9, a-f) are almost always a bad  
> choice, because a, c and e have no ascenders like every hindu-arabic  
> decimal digit has and thus make the number harder to read. This  
> obviously does not apply to fonts with old-style numerals aka. text  
> figures, where 0, 1 and 2 have neither ascenders (like 6 and 8) nor  
> descenders (like 3, 4, 5, 7 and 9), but those are rather unlikely to be  
> used in a programming environment.

I believe this, but I suspect that the gain in compatibility is well worth  
the minor loss in efficiency for people who are hand-coding.

Cheers

Chaals

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo espa?ol  -  je parle fran?ais  -  jeg l?rer norsk
chaals at opera.com          Try Opera 9 now! http://opera.com


From shadow2531 at gmail.com  Tue Sep  5 07:20:06 2006
From: shadow2531 at gmail.com (Shadow2531)
Date: Tue, 5 Sep 2006 10:20:06 -0400
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <44FCAD94.2050704@web.de>
References: <44E68AA7.8080008@web.de>
	<6b9c91b20608191008oc274b9dq39cc6f9aa025d8c1@mail.gmail.com>
	<44E932EC.1020507@mit.edu>
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>
	<44EA1A02.4090207@mit.edu>
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>
	<44F8F123.9010603@web.de>
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>
	<44FCAD94.2050704@web.de>
Message-ID: <6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>

On 9/4/06, Christian Biesinger <cbiesinger at web.de> 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 <object>), but that's all. It
> certainly doesn't map codebase to anything else.
> > As for the priority deal. Here's an example:
> >
> > <object codebase="http://somesite.com/dir/">
> >    <param name="baseurl" "http://someothersite.com/">
> > </object>
>
> 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, <param name="autostart" value="false" doesn't work for
WMP unless you're using activex. It has to be value="0" for it to work
for the netscape version.

I'd love to see it work with 'true", but ....

I think Gecko did map true -> 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


From bzbarsky at mit.edu  Tue Sep  5 08:35:34 2006
From: bzbarsky at mit.edu (Boris Zbarsky)
Date: Tue, 05 Sep 2006 10:35:34 -0500
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>
References: <44E68AA7.8080008@web.de>	
	<6b9c91b20608191008oc274b9dq39cc6f9aa025d8c1@mail.gmail.com>	
	<44E932EC.1020507@mit.edu>	
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>	
	<44EA1A02.4090207@mit.edu>	
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>	
	<44F8F123.9010603@web.de>	
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>	
	<44FCAD94.2050704@web.de>
	<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>
Message-ID: <44FD9946.2000905@mit.edu>

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.

-Boris


From contact at nickshanks.com  Tue Sep  5 10:07:35 2006
From: contact at nickshanks.com (Nicholas Shanks)
Date: Tue, 5 Sep 2006 18:07:35 +0100
Subject: [whatwg] return lowercase hex values for fillStyle and
	strokeStyle
In-Reply-To: <op.tfel0kciwxe0ny@widsith.local>
References: <op.te2afeqjaw9dld@id-c0020.oslo.opera.com>
	<2AADA27A-0DFA-46EC-B384-7754DF5FBDBB@crissov.de>
	<op.tfel0kciwxe0ny@widsith.local>
Message-ID: <3A69E3AC-30A9-4DAB-8896-CD593EF1B115@nickshanks.com>

On 5 Sep 2006, at 12:54, Charles McCathieNevile wrote:

>>> Instead of returning an uppercase six digit hex value I suggest  
>>> returning a lowercase value for compatibility with what UAs  
>>> (including IE) currently do
>>
>> It may be the right decision on compatibility grounds, but other  
>> than that lowercase hexadecimal digits (0-9, a-f) are almost  
>> always a bad choice, because a, c and e have no ascenders like  
>> every hindu-arabic decimal digit has and thus make the number  
>> harder to read. This obviously does not apply to fonts with old- 
>> style numerals aka. text figures, where 0, 1 and 2 have neither  
>> ascenders (like 6 and 8) nor descenders (like 3, 4, 5, 7 and 9),  
>> but those are rather unlikely to be used in a programming  
>> environment.
>
> I believe this, but I suspect that the gain in compatibility is  
> well worth the minor loss in efficiency for people who are hand- 
> coding.

I disagree, and always prefer uppercase hex digits to lowercase ones,  
it makes the numbers easier to read IMO.

- Nicholas.


From cbiesinger at web.de  Tue Sep  5 10:32:44 2006
From: cbiesinger at web.de (Christian Biesinger)
Date: Tue, 05 Sep 2006 10:32:44 -0700
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>
References: <44E68AA7.8080008@web.de>	
	<6b9c91b20608191008oc274b9dq39cc6f9aa025d8c1@mail.gmail.com>	
	<44E932EC.1020507@mit.edu>	
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>	
	<44EA1A02.4090207@mit.edu>	
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>	
	<44F8F123.9010603@web.de>	
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>	
	<44FCAD94.2050704@web.de>
	<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>
Message-ID: <44FDB4BC.3080105@web.de>

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?

> 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.

> 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?

> 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?




From chaals at opera.com  Tue Sep  5 10:48:33 2006
From: chaals at opera.com (Charles McCathieNevile)
Date: Tue, 05 Sep 2006 19:48:33 +0200
Subject: [whatwg] return lowercase hex values for fillStyle and
	strokeStyle
In-Reply-To: <3A69E3AC-30A9-4DAB-8896-CD593EF1B115@nickshanks.com>
References: <op.te2afeqjaw9dld@id-c0020.oslo.opera.com>
	<2AADA27A-0DFA-46EC-B384-7754DF5FBDBB@crissov.de>
	<op.tfel0kciwxe0ny@widsith.local>
	<3A69E3AC-30A9-4DAB-8896-CD593EF1B115@nickshanks.com>
Message-ID: <op.tfe2e7o7wxe0ny@widsith.local>

On Tue, 05 Sep 2006 19:07:35 +0200, Nicholas Shanks  
<contact at nickshanks.com> wrote:

> On 5 Sep 2006, at 12:54, Charles McCathieNevile wrote:
>
>>>> Instead of returning an uppercase six digit hex value I suggest  
>>>> returning a lowercase value for compatibility with what UAs  
>>>> (including IE) currently do
>>>
>>> It may be the right decision on compatibility grounds, but other than  
>>> that lowercase hexadecimal digits (0-9, a-f) are almost always a bad  
>>> choice, because a, c and e have no ascenders like every hindu-arabic  
>>> decimal digit has and thus make the number harder to read. This  
>>> obviously does not apply to fonts with old-style numerals aka. text  
>>> figures, where 0, 1 and 2 have neither ascenders (like 6 and 8) nor  
>>> descenders (like 3, 4, 5, 7 and 9), but those are rather unlikely to  
>>> be used in a programming environment.
>>
>> I believe this, but I suspect that the gain in compatibility is well  
>> worth the minor loss in efficiency for people who are hand-coding.
>
> I disagree, and always prefer uppercase hex digits to lowercase ones, it  
> makes the numbers easier to read IMO.

That is, I think, what Christopher said and I agreed with. I still think  
that compatibility with deployed browsers should, in this case, trump that  
usability gain.

cheers

Chaals

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo espa?ol  -  je parle fran?ais  -  jeg l?rer norsk
chaals at opera.com          Try Opera 9 now! http://opera.com


From shadow2531 at gmail.com  Tue Sep  5 10:56:46 2006
From: shadow2531 at gmail.com (Shadow2531)
Date: Tue, 5 Sep 2006 13:56:46 -0400
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <44FD9946.2000905@mit.edu>
References: <44E68AA7.8080008@web.de> <44E932EC.1020507@mit.edu>
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>
	<44EA1A02.4090207@mit.edu>
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>
	<44F8F123.9010603@web.de>
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>
	<44FCAD94.2050704@web.de>
	<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>
	<44FD9946.2000905@mit.edu>
Message-ID: <6b9c91b20609051056u59ae17a0ua9dfd2394d1835cf@mail.gmail.com>

On 9/5/06, Boris Zbarsky <bzbarsky at mit.edu> 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


From bzbarsky at mit.edu  Tue Sep  5 11:08:56 2006
From: bzbarsky at mit.edu (Boris Zbarsky)
Date: Tue, 05 Sep 2006 13:08:56 -0500
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <6b9c91b20609051056u59ae17a0ua9dfd2394d1835cf@mail.gmail.com>
References: <44E68AA7.8080008@web.de> <44E932EC.1020507@mit.edu>	
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>	
	<44EA1A02.4090207@mit.edu>	
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>	
	<44F8F123.9010603@web.de>	
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>	
	<44FCAD94.2050704@web.de>	
	<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>	
	<44FD9946.2000905@mit.edu>
	<6b9c91b20609051056u59ae17a0ua9dfd2394d1835cf@mail.gmail.com>
Message-ID: <44FDBD38.3020306@mit.edu>

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

It does.

> 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.

> 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?

-Boris


From fora at annevankesteren.nl  Tue Sep  5 11:51:33 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Tue, 05 Sep 2006 20:51:33 +0200
Subject: [whatwg] href on any element
In-Reply-To: <44FC645A.405@keryx.se>
References: <002401c6cb84$83a07350$0500a8c0@computername>
	<op.te14t6uc4suneb@g5.local> <44FC645A.405@keryx.se>
Message-ID: <op.tfe5b7xsaw9dld@id-c0020.oslo.opera.com>

On Mon, 04 Sep 2006 19:37:30 +0200, Keryx webb <webmaster at keryx.se> wrote:
> To make the whole LI-element clickable I have to resort to CSS
> ( ul#nav li a { display: block } ) which does not work in all browsers  
> or JavaScript, which also is a hassle.

Yeah, <li href="">test</li> does work in all browsers obviously. Seems  
like a good reason to put it in HTML5!


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From shadow2531 at gmail.com  Tue Sep  5 12:08:56 2006
From: shadow2531 at gmail.com (Shadow2531)
Date: Tue, 5 Sep 2006 15:08:56 -0400
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <44FDBD38.3020306@mit.edu>
References: <44E68AA7.8080008@web.de> <44EA1A02.4090207@mit.edu>
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>
	<44F8F123.9010603@web.de>
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>
	<44FCAD94.2050704@web.de>
	<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>
	<44FD9946.2000905@mit.edu>
	<6b9c91b20609051056u59ae17a0ua9dfd2394d1835cf@mail.gmail.com>
	<44FDBD38.3020306@mit.edu>
Message-ID: <6b9c91b20609051208g1617d9f9n12b26feff746437b@mail.gmail.com>

On 9/5/06, Boris Zbarsky <bzbarsky at mit.edu> 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


From jg307 at cam.ac.uk  Tue Sep  5 12:38:33 2006
From: jg307 at cam.ac.uk (James Graham)
Date: Tue, 05 Sep 2006 20:38:33 +0100
Subject: [whatwg] href on any element
In-Reply-To: <44FC645A.405@keryx.se>
References: <002401c6cb84$83a07350$0500a8c0@computername>	<op.te14t6uc4suneb@g5.local>
	<44FC645A.405@keryx.se>
Message-ID: <44FDD239.7030308@cam.ac.uk>

Keryx webb wrote:

> Will it break backwards compatibility? Yes, if todays browsers are 
> supposed to be able to render WHATWG-pages. But there are lots of other 
> things in WHATWG that they do not understand either. It's only the very 
> latest browsers that can handle canvas. No browser fully implements Web 
> Forms 2.0 (as far as I know).

But there is usually some way to use other HTML5/WF2 features without 
breaking current browsers. The only way I can see to do this with href 
on many elements is to manually walk the DOM inserting <a href="bar" /> 
elements as children of the <foo href="bar" /> elements, with some care 
needed for elements such as <tr> that really won't take <a> as a child. 
Authors doing this would also have to be very careful about not breaking 
their CSS rules etc. in current browsers.

href on multiple elements is a nice idea but I'm not sure the benefits 
outweigh the costs.


From shadow2531 at gmail.com  Tue Sep  5 12:48:55 2006
From: shadow2531 at gmail.com (Shadow2531)
Date: Tue, 5 Sep 2006 15:48:55 -0400
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <44FDB4BC.3080105@web.de>
References: <44E68AA7.8080008@web.de> <44E932EC.1020507@mit.edu>
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>
	<44EA1A02.4090207@mit.edu>
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>
	<44F8F123.9010603@web.de>
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>
	<44FCAD94.2050704@web.de>
	<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>
	<44FDB4BC.3080105@web.de>
Message-ID: <6b9c91b20609051248g1b04602ewcb22effdf99fa628@mail.gmail.com>

On 9/5/06, Christian Biesinger <cbiesinger at web.de> 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 :

<object type="application/x-shockwave-flash"
codebase="http://www.adobe.com/"
data="shockwave/download/triggerpages_mmcom/flash.swf" width="300"
height="120"></object>

> > 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


From mattraymond at earthlink.net  Tue Sep  5 16:27:28 2006
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Tue, 05 Sep 2006 19:27:28 -0400
Subject: [whatwg] Modal Dialog Box support
In-Reply-To: <5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>	<BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>	<005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>
	<5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com>
Message-ID: <44FE07E0.9080308@earthlink.net>

Rimantas Liubertas wrote:
[Snip!]
> Chapter 30 "Using Dialogs" in "About the Face 2.0" [1] by Alan Cooper
> makes a good
> read too.
> 
> [1] http://www.amazon.com/About-Face-2-0-Essentials-Interaction/dp/0764526413/sr=8-1/qid=1157449548/ref=pd_bbs_1/102-1456987-0371351?ie=UTF8&s=books


   So, what, we're supposed to order and read a book from Amazon.com in
order to know what you're talking about?


From cbiesinger at web.de  Tue Sep  5 19:45:04 2006
From: cbiesinger at web.de (Christian Biesinger)
Date: Tue, 05 Sep 2006 19:45:04 -0700
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <6b9c91b20609051248g1b04602ewcb22effdf99fa628@mail.gmail.com>
References: <44E68AA7.8080008@web.de> <44E932EC.1020507@mit.edu>	
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>	
	<44EA1A02.4090207@mit.edu>	
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>	
	<44F8F123.9010603@web.de>	
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>	
	<44FCAD94.2050704@web.de>	
	<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>	
	<44FDB4BC.3080105@web.de>
	<6b9c91b20609051248g1b04602ewcb22effdf99fa628@mail.gmail.com>
Message-ID: <44FE3630.7090002@web.de>

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

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

> 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.

> 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.

It does help something. It helps all browser makers by not finding out 
what specific hacks certain plugins want when the right place to fix it 
is in the plugin itself.

> 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 :)

Anyway... we seem to have some disagreement... and this is perhaps not 
even in the scope of a spec that describes HTML... so guess we'll leave 
it at that :)

-christian


From cbiesinger at web.de  Tue Sep  5 19:48:33 2006
From: cbiesinger at web.de (Christian Biesinger)
Date: Tue, 05 Sep 2006 19:48:33 -0700
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <44FDBD38.3020306@mit.edu>
References: <44E68AA7.8080008@web.de>
	<44E932EC.1020507@mit.edu>		<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>		<44EA1A02.4090207@mit.edu>		<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>		<44F8F123.9010603@web.de>		<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>		<44FCAD94.2050704@web.de>		<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>		<44FD9946.2000905@mit.edu>	<6b9c91b20609051056u59ae17a0ua9dfd2394d1835cf@mail.gmail.com>
	<44FDBD38.3020306@mit.edu>
Message-ID: <44FE3701.6080309@web.de>

Boris Zbarsky wrote:
>> 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.

Well that depends on the plugin, the other way (the one I consider 
normal ;) ) gives the plugin the actual chunks of data sequentially. 
Guess that amounts to almost the same.


From shadow2531 at gmail.com  Wed Sep  6 05:10:22 2006
From: shadow2531 at gmail.com (Shadow2531)
Date: Wed, 6 Sep 2006 08:10:22 -0400
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <44FE3630.7090002@web.de>
References: <44E68AA7.8080008@web.de> <44EA1A02.4090207@mit.edu>
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>
	<44F8F123.9010603@web.de>
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>
	<44FCAD94.2050704@web.de>
	<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>
	<44FDB4BC.3080105@web.de>
	<6b9c91b20609051248g1b04602ewcb22effdf99fa628@mail.gmail.com>
	<44FE3630.7090002@web.de>
Message-ID: <6b9c91b20609060510l56dc8aa1j200a9cf3ac7ea00e@mail.gmail.com>

On 9/5/06, Christian Biesinger <cbiesinger at web.de> wrote:
> Shadow2531 wrote:
> > The FF ( trunk or 1.5.0.6) codebase problem doesn't happen with Flash
> > as you can see from :
> >
> > <object type="application/x-shockwave-flash"
> > codebase="http://www.adobe.com/"
> > data="shockwave/download/triggerpages_mmcom/flash.swf" width="300"
> > height="120"></object>
>
> 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


From chaals at opera.com  Wed Sep  6 07:44:54 2006
From: chaals at opera.com (Charles McCathieNevile)
Date: Wed, 06 Sep 2006 16:44:54 +0200
Subject: [whatwg] Modal Dialog Box support
In-Reply-To: <44FE07E0.9080308@earthlink.net>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>
	<BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>
	<005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>
	<5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com>
	<44FE07E0.9080308@earthlink.net>
Message-ID: <op.tfgok4kfwxe0ny@widsith.local>

On Wed, 06 Sep 2006 01:27:28 +0200, Matthew Raymond  
<mattraymond at earthlink.net> wrote:

> Rimantas Liubertas wrote:
> [Snip!]
>> Chapter 30 "Using Dialogs" in "About the Face 2.0" [1] by Alan Cooper
>> makes a good read too.
>>
>> [1]  
>> http://www.amazon.com/About-Face-2-0-Essentials-Interaction/dp/0764526413/sr=8-1/qid=1157449548/ref=pd_bbs_1/102-1456987-0371351?ie=UTF8&s=books
>
>
>    So, what, we're supposed to order and read a book from Amazon.com in
> order to know what you're talking about?

You could always go to a library. I believe the reference was offered as  
something useful, should you be inclined to take the time.

Cheers

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo espa?ol  -  je parle fran?ais  -  jeg l?rer norsk
chaals at opera.com          Try Opera 9 now! http://opera.com


From jg307 at cam.ac.uk  Wed Sep  6 08:46:02 2006
From: jg307 at cam.ac.uk (James Graham)
Date: Wed, 06 Sep 2006 16:46:02 +0100
Subject: [whatwg] Modal Dialog Box support
In-Reply-To: <op.tfgok4kfwxe0ny@widsith.local>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>	<BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>	<005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>	<5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com>	<44FE07E0.9080308@earthlink.net>
	<op.tfgok4kfwxe0ny@widsith.local>
Message-ID: <44FEED3A.1000004@cam.ac.uk>

Charles McCathieNevile wrote:
> On Wed, 06 Sep 2006 01:27:28 +0200, Matthew Raymond 
> <mattraymond at earthlink.net> wrote:
> 
>> Rimantas Liubertas wrote:
>> [Snip!]
>>> Chapter 30 "Using Dialogs" in "About the Face 2.0" [1] by Alan Cooper
>>> makes a good read too.
>>>
>>> [1] 
>>> http://www.amazon.com/About-Face-2-0-Essentials-Interaction/dp/0764526413/sr=8-1/qid=1157449548/ref=pd_bbs_1/102-1456987-0371351?ie=UTF8&s=books 
>>>
>>
>>
>>    So, what, we're supposed to order and read a book from Amazon.com in
>> order to know what you're talking about?
> 
> You could always go to a library. I believe the reference was offered as 
> something useful, should you be inclined to take the time.

But it would be even more useful if we got a short summary of _why_ the chapter 
is useful reading material and what point it contributes to the discussion. At 
the /very least/ something like:

Chapter 30 "Using Dialogs" in "About the Face 2.0" [1] by Alan Cooper makes a 
good read too. It explains that modal dialogs are never a good idea because they 
force the user to work on the computer's terms, rather than the other way 
around. It deals specifically with the issue of databases and suggests ways of 
designing the interface without resorting to user-hostile modal behaviour.

[note: that's all fiction, in case it wasn't obvious. I have no idea if that 
book has even been published in this country]

Even with a short description, you have to bear in mind that the book may not 
have widespread international distribution or may otherwise be hard to find.

-- 
"Eternity's a terrible thought. I mean, where's it all going to end?"
  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead


From mattraymond at earthlink.net  Wed Sep  6 11:46:52 2006
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Wed, 06 Sep 2006 14:46:52 -0400
Subject: [whatwg] Modal Dialog Box support
In-Reply-To: <op.tfgok4kfwxe0ny@widsith.local>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>	<BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>	<005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>	<5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com>	<44FE07E0.9080308@earthlink.net>
	<op.tfgok4kfwxe0ny@widsith.local>
Message-ID: <44FF179C.8040609@earthlink.net>

Charles McCathieNevile wrote:
>>    So, what, we're supposed to order and read a book from Amazon.com in
>> order to know what you're talking about?
> 
> You could always go to a library. I believe the reference was offered as  
> something useful, should you be inclined to take the time.

   There's three problems with this thinking:

1) Not everyone lives near a public library with a wide selection of
computer science books.

2) Not everyone has the time and the gasoline (which is expensive these
days) to go to the library every time someone references a book on a
mailing list.

3) Response to the email in question is delayed while the reader is
hunting for a book.

   James Graham was more tactful about this, and I suppose I could have
myself been a little more tactful to the person who posted the
Amazon.com link, but I want it to be clear that it's not acceptable for
someone to have to be well read to participate in this mailing list. As
such, your comment may be seen by some as elitist.


From anders.rundgren at telia.com  Wed Sep  6 11:54:54 2006
From: anders.rundgren at telia.com (Anders Rundgren)
Date: Wed, 6 Sep 2006 20:54:54 +0200
Subject: [whatwg] Modal Dialog Box support
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v><BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de><005f01c6d0cd$e9fb2020$82c5a8c0@arport2v><5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com><44FE07E0.9080308@earthlink.net>
	<op.tfgok4kfwxe0ny@widsith.local>
Message-ID: <005101c6d1e5$f1558ef0$82c5a8c0@arport2v>

I assume Opera and Mozilla will remove modality from alert () from
the next major releases?

People probably just can't wait to put their hands on a browser that will
finally free them from the Windows-style programming tyranny :-)

OEM vendors such as Opera should IMHO be a little bit cautious about
neglecting the [perceived] needs of the [somewhat uneducated] mainstream.
Fools may turn out as pretty good buyers!

thanx,
Anders Rundgren
Developer of legacy apps, but for the web

----- Original Message -----
From: "Charles McCathieNevile" <>
To: "Matthew Raymond" <mattraymond at earthlink.net>; "Rimantas Liubertas" <rimantas at gmail.com>
Cc: <whatwg at lists.whatwg.org>
Sent: Wednesday, September 06, 2006 16:44
Subject: Re: [whatwg] Modal Dialog Box support


On Wed, 06 Sep 2006 01:27:28 +0200, Matthew Raymond
<mattraymond at earthlink.net> wrote:

> Rimantas Liubertas wrote:
> [Snip!]
>> Chapter 30 "Using Dialogs" in "About the Face 2.0" [1] by Alan Cooper
>> makes a good read too.
>>
>> [1]
>>
http://www.amazon.com/About-Face-2-0-Essentials-Interaction/dp/0764526413/sr=8-1/qid=1157449548/ref=pd_bbs_1/102-1456987-0371351?ie=
UTF8&s=books
>
>
>    So, what, we're supposed to order and read a book from Amazon.com in
> order to know what you're talking about?

You could always go to a library. I believe the reference was offered as
something useful, should you be inclined to take the time.

Cheers

--
   Charles McCathieNevile, Opera Software: Standards Group
   hablo espa?ol  -  je parle fran?ais  -  jeg l?rer norsk
chaals at opera.com          Try Opera 9 now! http://opera.com




From chaals at opera.com  Wed Sep  6 12:54:05 2006
From: chaals at opera.com (Charles McCathieNevile)
Date: Wed, 06 Sep 2006 21:54:05 +0200
Subject: [whatwg] Books and rhetoric Re:  Modal Dialog Box support
In-Reply-To: <44FF179C.8040609@earthlink.net>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>
	<BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>
	<005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>
	<5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com>
	<44FE07E0.9080308@earthlink.net> <op.tfgok4kfwxe0ny@widsith.local>
	<44FF179C.8040609@earthlink.net>
Message-ID: <op.tfg2wfowwxe0ny@widsith.local>

On Wed, 06 Sep 2006 20:46:52 +0200, Matthew Raymond  
<mattraymond at earthlink.net> wrote:

> Charles McCathieNevile wrote:
>>>    So, what, we're supposed to order and read a book from Amazon.com in
>>> order to know what you're talking about?
>>
>> You could always go to a library. I believe the reference was offered as
>> something useful, should you be inclined to take the time.

Sorry if I was impolite. It was not my intention, but in any case I will  
make a bigger effort to be tactful.

> 1) Not everyone lives near a public library with a wide selection of
> computer science books.

Quite. Some people also have the luxury of a public library system that  
will if necessary ship books loaned from other libraries (librarians  
worked pretty hard to make systems like this work. t is a shame if people  
no longer realise what they have...).

> 2) Not everyone has the time and the gasoline (which is expensive these
> days) to go to the library every time someone references a book on a
> mailing list.

Naturally. The same as your point that not everyone can buy the book and  
read it.

> 3) Response to the email in question is delayed while the reader is
> hunting for a book.

Of course, if the discussion is based on the book to the extent that it is  
necessary to read it in order to take further part. (There are cases where  
that is justifiable, of course. Discussing the details of a piece of  
research without having read it is a bit pointless...)

>    James Graham was more tactful about this, and I suppose I could have
> myself been a little more tactful to the person who posted the
> Amazon.com link, but I want it to be clear that it's not acceptable for
> someone to have to be well read to participate in this mailing list. As
> such, your comment may be seen by some as elitist.

"something useful, should you be inclined to take the time" was meant to  
imply that it is not essential, but those who want to become ridiculously  
well-read? might find it interesting. My impression was that reading this  
book was not core to understanding the statement, just that it laid out  
what is presumably a similar argument in more detail.

Reductio ad absurdum (what you did, taking my argument to its logical  
extreme to show that it is of limited value) cuts both ways. There is no  
requirement that people know anything at all about the Web to participate  
on this list, although it would be a waste of almost everyone's time.

It strikes me as pretty obvious that being well read will increase the  
value of your contribution, and probably what you gain from this list as  
well. That does not mean you should read every book somone names, but nor  
should you expect people to restrict their statements to things that do  
not rely on any research that is only published in a form that requires  
payment (although good manners is, as James suggested, to at least  
summarise such information here for those who don't have a limitless  
book-buying budget and the spare time to sit and read every stray scrap  
that passes by).

I am quite content to be accused of saying that people who know more can  
better contribute. I do not at all subscribe to the idea that you must be  
ridiculously well-read? to participate, nor do you have to be so to have  
very valuable contributions to make. (Some people will criticise me  
whatever I say. Others will always agree and praise it. For the most part,  
neither of these groups are very interesting).

Cheers

Chaals

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo espa?ol  -  je parle fran?ais  -  jeg l?rer norsk
chaals at opera.com          Try Opera 9 now! http://opera.com


From mattraymond at earthlink.net  Wed Sep  6 19:39:36 2006
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Wed, 06 Sep 2006 22:39:36 -0400
Subject: [whatwg] Books and rhetoric Re:  Modal Dialog Box support
In-Reply-To: <op.tfg2wfowwxe0ny@widsith.local>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>
	<BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>
	<005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>
	<5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com>
	<44FE07E0.9080308@earthlink.net> <op.tfgok4kfwxe0ny@widsith.local>
	<44FF179C.8040609@earthlink.net> <op.tfg2wfowwxe0ny@widsith.local>
Message-ID: <44FF8668.7050109@earthlink.net>

Charles McCathieNevile wrote:
> On Wed, 06 Sep 2006 20:46:52 +0200, Matthew Raymond  
>> 3) Response to the email in question is delayed while the reader is
>> hunting for a book.
> 
> Of course, if the discussion is based on the book to the extent that it is  
> necessary to read it in order to take further part. (There are cases where  
> that is justifiable, of course. Discussing the details of a piece of  
> research without having read it is a bit pointless...)

   Rimantas's entire email was this:

   "Chapter 30 'Using Dialogs' in 'About the Face 2.0' by Alan Cooper
makes a good read too."

   There's nothing you can clearly determine about his meaning without
reading the book he refers to. That is not the same as a conversation
regarding the 9/ll Report, for instance, where you'll be specifically
talking about a literary source, because the thread is not about "About
the Face 2.0". Furthermore, I fail to see the value of limiting a public
conversation on standards because one or two people want to argue about
one book.

>>    James Graham was more tactful about this, and I suppose I could have
>> myself been a little more tactful to the person who posted the
>> Amazon.com link, but I want it to be clear that it's not acceptable for
>> someone to have to be well read to participate in this mailing list. As
>> such, your comment may be seen by some as elitist.
> 
> "something useful, should you be inclined to take the time" was meant to  
> imply that it is not essential, but those who want to become ridiculously  
> well-read? might find it interesting. My impression was that reading this  
> book was not core to understanding the statement, just that it laid out  
> what is presumably a similar argument in more detail.

   Upon reexamination of the email, he does appear to be making a casual
reference as you state. Hence my remark that I should have been more
tactful.

> Reductio ad absurdum (what you did, taking my argument to its logical  
> extreme to show that it is of limited value) cuts both ways. There is no  
> requirement that people know anything at all about the Web to participate  
> on this list, although it would be a waste of almost everyone's time.

   The difference here is that someone with little access to books can
still read web specifications and articles that are on the Internet.
There are two classifications of information here. The original
reference that started this conversation was to a book that you'd
probably have to mail order because it's not necessarily that common.
Contrast that with any specification on the W3C website and you can
clearly see that they differ greatly with regards to access. If you
refer to web content, a smart but uneducated person can quickly come up
to speed, whereas books take time to acquire, can be quite expensive in
some cases, and are not searchable.

> It strikes me as pretty obvious that being well read will increase the  
> value of your contribution, and probably what you gain from this list as  
> well. That does not mean you should read every book [someone] names, but nor  
> should you expect people to restrict their statements to things that do  
> not rely on any research that is only published in a form that requires  
> payment (although good manners is, as James suggested, to at least  
> summarise such information here for those who don't have a limitless  
> book-buying budget and the spare time to sit and read every stray scrap  
> that passes by).

   It wasn't just about good manners. If you go back and read the
message, you have no way of knowing what the author's position is on
modal dialogs unless you read the specified chapter of the book he
linked to. Not only could the author have made some statement about the
contents of the book, thus allowing us to understand both his position
and why we'd want to read the book, but under U.S. copyright law he
could have included a brief excerpt of the book's text as well.

   So this isn't just about manners. Referencing supporting material as
the sole means of communicating your argument serves a barrier to
further conversation and debate, even if the argument is offered in a
causal manner.

> I am quite content to be accused of saying that people who know more can  
> better contribute. I do not at all subscribe to the idea that you must be  
> ridiculously well-read? to participate, nor do you have to be so to have  
> very valuable contributions to make. (Some people will criticise me  
> whatever I say. Others will always agree and praise it. For the most part,  
> neither of these groups are very interesting).

   No message can please all the people all the time, but if the people
don't have the resources to devote to deciphering a message in the first
place, it won't matter if they like it or not because they'll never be
able to understand it. Encryption-by-book-reference is bad.


From ajvincent at gmail.com  Wed Sep  6 21:40:34 2006
From: ajvincent at gmail.com (Alex Vincent)
Date: Wed, 6 Sep 2006 21:40:34 -0700
Subject: [whatwg] WF2: required attribute clarification requested
Message-ID: <9301ed6b0609062140r372e8e6dq90b0b069bafacf7d@mail.gmail.com>

"For disabled or readonly controls, the (required) attribute has no effect."

What does this mean?  The missingValue bit of validityState is either
on or off.  Do I need to change the required bit if we're disabled?
Or should I leave it alone?

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001


From anders.rundgren at telia.com  Wed Sep  6 23:16:35 2006
From: anders.rundgren at telia.com (Anders Rundgren)
Date: Thu, 7 Sep 2006 08:16:35 +0200
Subject: [whatwg] HTLM5 - Addressing the Password Craze?
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v><BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de><005f01c6d0cd$e9fb2020$82c5a8c0@arport2v><5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com><44FE07E0.9080308@earthlink.net><op.tfgok4kfwxe0ny@widsith.local>
	<005101c6d1e5$f1558ef0$82c5a8c0@arport2v>
Message-ID: <004901c6d245$2c65e710$82c5a8c0@arport2v>

Dear all,
As you probably have noticed, practically every site offers a login.for their
members, customers, citizens etc. etc.

There are two problems here.
1.   User-id/password management has become a real nuisance. Once this was
an issue for computer professionals only, now it affects everyone from children
to grandma.

2. There are other and better authentication methods available that become hard
to migrate to without making life hard for end-users by asking them to use another
login method.  The site has no way of detecting the user's options.

It appears, that it may be possible to add some kind of negotiation/option
elements at the HTML level, that if supported by the underlying system could
offer a standardized and potentially more powerful version of the password
caches or external login form "hijacker software" that we currently use. 
Tentative functionality for the AHE (Authentication Helper Extension):

- Find out if the AHE is installed/available

- If the AHE is available, find out if the site in question is in the list

- If in the list, put out a dialog box giving the user an option to login, decline
  or manually enter login information. 

- If the site so requests, the user's authentication options (in case form based
  authentication was used) can be transferred during login, giving the site an
  option to ask/require the user to upgrade their authentication.  This could
  involve anything from digest-authentication to certificates.  The latter
  current lacks a decent provision method but there is some work 
  going on in this area as well.  MS CardSpaces is also an option.

- The authentication stuff would be possible to store in an USB token or
  even better in a mobile phone.  This is of course outside of HTML5
  but will be natural to support within 3-5 years from now.

- The scheme would (if properly implemented) be able to thwart phishing
  since a user-id/password (or other auth solution) could be tied to a
  SSL root + host name (or even better host domain).

In essence the desired result is a portable (mobile) multi-site authentication
 support mechanism that should not only make the web easier, but also
long-term considerably more secure.  

Other Options?
==========
The other option is addressing this problem at the transport level but I think
form-based authentication is a better entrance point since it is already in place.
There is no problem [at all] of having a mechanism [in the proposed scheme]
that switches from form-based authentication to transport-level authentication
like using TLS-client-certificates, while the opposite is impossible.

Sincerely
Anders Rundgren




From anders.rundgren at telia.com  Wed Sep  6 23:27:24 2006
From: anders.rundgren at telia.com (Anders Rundgren)
Date: Thu, 7 Sep 2006 08:27:24 +0200
Subject: [whatwg] HTML Was:HTLM5 - Addressing the Password Craze?
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v><BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de><005f01c6d0cd$e9fb2020$82c5a8c0@arport2v><5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com><44FE07E0.9080308@earthlink.net><op.tfgok4kfwxe0ny@widsith.local><005101c6d1e5$f1558ef0$82c5a8c0@arport2v>
	<004901c6d245$2c65e710$82c5a8c0@arport2v>
Message-ID: <006c01c6d246$aebaa8d0$82c5a8c0@arport2v>

Pardon,
I hope that you read the rest in spite of the fact that I screw-up already in the subject line. :-(
Please correct the spelling in answer threads.
Anders

----- Original Message ----- 
From: "Anders Rundgren" <anders.rundgren at telia.com>
To: <whatwg at lists.whatwg.org>
Cc: "Sam Hartman" <hartmans-ietf at mit.edu>
Sent: Thursday, September 07, 2006 08:16
Subject: [whatwg] HTLM5 - Addressing the Password Craze?


Dear all,
As you probably have noticed, practically every site offers a login.for their
members, customers, citizens etc. etc.

There are two problems here.
1.   User-id/password management has become a real nuisance. Once this was
an issue for computer professionals only, now it affects everyone from children
to grandma.

2. There are other and better authentication methods available that become hard
to migrate to without making life hard for end-users by asking them to use another
login method.  The site has no way of detecting the user's options.

It appears, that it may be possible to add some kind of negotiation/option
elements at the HTML level, that if supported by the underlying system could
offer a standardized and potentially more powerful version of the password
caches or external login form "hijacker software" that we currently use. 
Tentative functionality for the AHE (Authentication Helper Extension):

- Find out if the AHE is installed/available

- If the AHE is available, find out if the site in question is in the list

- If in the list, put out a dialog box giving the user an option to login, decline
  or manually enter login information. 

- If the site so requests, the user's authentication options (in case form based
  authentication was used) can be transferred during login, giving the site an
  option to ask/require the user to upgrade their authentication.  This could
  involve anything from digest-authentication to certificates.  The latter
  current lacks a decent provision method but there is some work 
  going on in this area as well.  MS CardSpaces is also an option.

- The authentication stuff would be possible to store in an USB token or
  even better in a mobile phone.  This is of course outside of HTML5
  but will be natural to support within 3-5 years from now.

- The scheme would (if properly implemented) be able to thwart phishing
  since a user-id/password (or other auth solution) could be tied to a
  SSL root + host name (or even better host domain).

In essence the desired result is a portable (mobile) multi-site authentication
 support mechanism that should not only make the web easier, but also
long-term considerably more secure.  

Other Options?
==========
The other option is addressing this problem at the transport level but I think
form-based authentication is a better entrance point since it is already in place.
There is no problem [at all] of having a mechanism [in the proposed scheme]
that switches from form-based authentication to transport-level authentication
like using TLS-client-certificates, while the opposite is impossible.

Sincerely
Anders Rundgren






From ian at hixie.ch  Thu Sep  7 07:27:46 2006
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 7 Sep 2006 07:27:46 -0700
Subject: [whatwg] WF2: required attribute clarification requested
In-Reply-To: <9301ed6b0609062140r372e8e6dq90b0b069bafacf7d@mail.gmail.com>
References: <9301ed6b0609062140r372e8e6dq90b0b069bafacf7d@mail.gmail.com>
Message-ID: <403d38e20609070727m3a0e77aet592c40c9f97be86a@mail.gmail.com>

I hear that this question is blocking implementation work so I'm going
to quickly reply to this despite being on holiday. :-)

On 9/6/06, Alex Vincent <ajvincent at gmail.com> wrote:
> "For disabled or readonly controls, the (required) attribute has no effect."
>
> What does this mean?

>From an implementor's point of view, it means nothing at all, because
it isn't a conformance statement (it has no "must", "should", "may",
etc) and isn't a definition (it doesn't define a term). Thus, for your
sake it can be ignored.

> The missingValue bit of validityState is either
> on or off.  Do I need to change the required bit if we're disabled?
> Or should I leave it alone?

missingValue, as defined, is unaffected by whether the control is
disabled or readonly -- it still gets set to true if the value is
missing -- but the control is not validated if it is disabled or
readonly, so it has no effect on submission, which is what I meant by
that sentence.

I'll clarify the spec when I get back from vacation. Right now it's
not very clear when the validity properties get set and when they
don't, which is unfortunate.

HTH,
-- 
Ian Hickson


From davebacher at hotmail.com  Thu Sep  7 17:38:36 2006
From: davebacher at hotmail.com (Dave Bacher)
Date: Thu, 07 Sep 2006 20:38:36 -0400
Subject: [whatwg] HTLM5 - Addressing the Password Craze?
In-Reply-To: <004901c6d245$2c65e710$82c5a8c0@arport2v>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v><BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de><005f01c6d0cd$e9fb2020$82c5a8c0@arport2v><5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com><44FE07E0.9080308@earthlink.net><op.tfgok4kfwxe0ny@widsith.local>	<005101c6d1e5$f1558ef0$82c5a8c0@arport2v>
	<004901c6d245$2c65e710$82c5a8c0@arport2v>
Message-ID: <BAY107-DAV151583511E2D4BFA7DAEDDC6370@phx.gbl>

Why not just issue a TLS 1 certificate?

Internet Explorer 2 and later support it.  Netscape Navigator 2 and 
later support it.  All versions of Opera support it.  All versions of 
FireFox support it.  All versions of Safari support it.  In fact, the 
vast majority of libraries and user agents that support TLS or even SSL 
websites also support TLS 1 client certificates.

When you issue the certificate, most browsers offer a convenient way to 
send it to the client.  It is installed into the local certificate 
store, or potentially a hardware device such as a smart card.  Later, 
the user authenticates to the user agent, and then is given the option 
of providing the certificate to a site that asks for it.  You can either 
issue a certificate specifically for your site, or you can have them go 
get a (freely available, in at least some cases) client certificate from 
a vendor like VeriSign.  These are typically called "e-mail signing 
certificates" or "digital ID's" by the companies that sell them.

There are a couple big benefits here.  First, you are using an existing 
user agent feature, that every user agent is likely to support.  So you 
just have to talk the user through installing the certificate into IE.

Secondly, web server side, it is a radio button in IIS 4 or later (not 
sure about earlier versions), or a single line in Apache to enable the 
feature.

Thirdly, if the ID becomes compromised, you can issue a revoke request, 
and issue a new ID.  This means the certificate that you issued before 
immediately becomes invalid, and so if the user loses the certificate or 
has it stollen, it takes no effort.

Fourthly, if the computer has a smart card reader (about USD $20) and a 
smart card, the certificate can be installed onto the smart card.  If 
this is done, then the user must provide a valid PIN in conjunction with 
the physical card in order to send data using the identities installed 
onto the card.  This adds a physical layer of security that is not 
possible with a name/password system.

And the worse problem than the number of systems using user id/password 
on a form to authenticate (and not at least using digest) is that many 
of these don't use TLS, and so the password is sent plain text or plain 
text equivalent across the network.  Additionally, many of these systems 
send the username and password pair by e-mail, which means not only is 
the user name and password sent across the internet, but also that it is 
stored in one or more well known locations on the user's computer for at 
least some period of time.  Since most operating systems don't provide 
any mechanism to lock down a directory so that only one module or 
application can access it, and since the most protection most user 
agents offer to e-mail files is the non-protection of a randomly 
generated file name, this is actually the worst part of the security risk.

Failing TLS, most servers (including IIS and Apache) and user agents 
support Kerberos, NTLM and a host of other options, and there are 
several publicly available specifications for what is called "Federated 
Identity."  The problem with all of these is that various parties have 
interests in pushing their own view of how a federated identity should 
work, usually to further their own goals.

Also, keep in mind that a federated identity system also poses privacy 
risks for the user.  When the user connects to your site, you must 
contact the federation and ask if they are who they say that they are.  
This means the federation knows both who you are, and what site you are 
trying to access.  This is why they aren't popular.

TLS doesn't have that problem, because you retrieve a certificate 
revocation list versus asking if a specific certificate is valid.  All 
that verisign (as an example) knows is that a TLS website asked for a 
revocation list, they don't ever know what user it was who was trying to 
access the site.

The issue with a federated log on is you must log on and log off from 
the federation site.  Sites have to check with that site to see if your 
token is valid or not, so any token based authentication inherently 
compromises your privacy (at least potentially).

Anders Rundgren wrote:
> Dear all,
> As you probably have noticed, practically every site offers a login.for their
> members, customers, citizens etc. etc.
>
> There are two problems here.
> 1.   User-id/password management has become a real nuisance. Once this was
> an issue for computer professionals only, now it affects everyone from children
> to grandma.
>
> 2. There are other and better authentication methods available that become hard
> to migrate to without making life hard for end-users by asking them to use another
> login method.  The site has no way of detecting the user's options.
>
> It appears, that it may be possible to add some kind of negotiation/option
> elements at the HTML level, that if supported by the underlying system could
> offer a standardized and potentially more powerful version of the password
> caches or external login form "hijacker software" that we currently use. 
> Tentative functionality for the AHE (Authentication Helper Extension):
>
> - Find out if the AHE is installed/available
>
> - If the AHE is available, find out if the site in question is in the list
>
> - If in the list, put out a dialog box giving the user an option to login, decline
>   or manually enter login information. 
>
> - If the site so requests, the user's authentication options (in case form based
>   authentication was used) can be transferred during login, giving the site an
>   option to ask/require the user to upgrade their authentication.  This could
>   involve anything from digest-authentication to certificates.  The latter
>   current lacks a decent provision method but there is some work 
>   going on in this area as well.  MS CardSpaces is also an option.
>
> - The authentication stuff would be possible to store in an USB token or
>   even better in a mobile phone.  This is of course outside of HTML5
>   but will be natural to support within 3-5 years from now.
>
> - The scheme would (if properly implemented) be able to thwart phishing
>   since a user-id/password (or other auth solution) could be tied to a
>   SSL root + host name (or even better host domain).
>
> In essence the desired result is a portable (mobile) multi-site authentication
>  support mechanism that should not only make the web easier, but also
> long-term considerably more secure.  
>
> Other Options?
> ==========
> The other option is addressing this problem at the transport level but I think
> form-based authentication is a better entrance point since it is already in place.
> There is no problem [at all] of having a mechanism [in the proposed scheme]
> that switches from form-based authentication to transport-level authentication
> like using TLS-client-certificates, while the opposite is impossible.
>
> Sincerely
> Anders Rundgren
>
>
>
>
>   






From dsr at w3.org  Fri Sep  8 09:40:34 2006
From: dsr at w3.org (Dave Raggett)
Date: Fri, 8 Sep 2006 17:40:34 +0100 (BST)
Subject: [whatwg] Hacking away on forms ... (fwd)
Message-ID: <Pine.LNX.4.64.0609081735250.5305@holly>

H&kon suggested I forward this to the whatwg list, so here goes.

  Dave Raggett <dsr at w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

---------- Forwarded message ----------
Date: Fri, 8 Sep 2006 16:38:50 +0100 (BST)
From: Dave Raggett <dsr at w3.org>
To: howcome at opera.com
Subject: Hacking away on forms ...

Hi H&kon,

I am hacking away at a cross platform JavaScript library for a 
forms-lite testbed, and hope to contribute to a compromise between 
the WebForms 2.0 and XForms camps. It seems to me that there is an 
opportunity to provide an incremental enhancement to HTML4 forms, 
that is easy to learn, reduces the amount of scripting authors have 
to do, and importantly, is a smooth stepping stone towards the use 
of XForms. What follows is an overview of what I am implementing. 
The testbed will be available in October (I am travelling too much 
in September).

The changes to the input element largely reflect what is in WF2 with 
some additions designed to reduce the need for authors to write 
client side scripts. The validate attribute is a boolean expression 
over fields names. If the value doesn't match the type and validate 
attributes the "invalid" class value is set on the element and may 
be used to alter the styling. The requires attribute is a boolean 
expression like validate, and indicates a value is required. As an 
example, you might be asked to give the name of a guardian if you 
said that your age is under 15. The required attribute could also be 
used on div elements to reveal/hide groups of controls (via an 
associated class value). You can also designate div and fieldset 
elements as repeating groups of controls. The index for a repeated 
group may be used within expressions for constraints within and 
across groups.

A major difference from WF2 is the use of the model-view-controller 
design pattern. The input elements act as presentations with the 
model held as JavaScript objects. This allows for multiple views to 
be kept in sync, as well as orchestrating updates to output fields. 
The getters and setters are associated with the field types, and the 
set of types can be extended by authors if needed. The model is 
automatically determined from the input elements and greatly reduces 
the amount of markup compared with XForms.

p.s. implementing the output element would be a lot cleaner if more 
browsers supported the /> syntax for empty elements that aren't part 
of traditional HTML. IE already does so, but Firefox and Opera do 
not. Firefox is even worse as it coerces the tag name to upper case 
when you inspect the DOM node it creates! Opera and Firefox also 
differ over the amount of whitespace text nodes that are set as the 
content on unknown elements. IE has its own weird worts, although 
strangely, it works rather nicely for non-html markup in XML 
namespaces. IE therefore encourages the use of XML namespaces for 
mixed markup when delivered as text/html.


From staikos at kde.org  Thu Sep  7 23:45:31 2006
From: staikos at kde.org (George Staikos)
Date: Fri, 8 Sep 2006 02:45:31 -0400
Subject: [whatwg] HTLM5 - Addressing the Password Craze?
In-Reply-To: <BAY107-DAV151583511E2D4BFA7DAEDDC6370@phx.gbl>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>
	<004901c6d245$2c65e710$82c5a8c0@arport2v>
	<BAY107-DAV151583511E2D4BFA7DAEDDC6370@phx.gbl>
Message-ID: <200609080245.31869.staikos@kde.org>


I would like to add a few more points here.

1) The hardware is very cumbersome.  It's not pervasive, it requires carrying 
cards and tokens, and limits mobility.
2) Certificates are more easily stolen than passwords unless the certificates 
have passwords on them.  Then, well, we are using passwords again.  
Certificates have lost most of their value by this point I think.
3) Users just don't understand this stuff yet.  In the case of a system 
failure most users will be completely lost with how to recover.
4) People are aware of the vulnerabilities of passwords and take at least some 
reasonable precautions with them.  Certificates are not infallible and people 
are not aware of how to properly protect them.

  Simplicity is golden here, as long as we don't truly compromise security.  I 
don't think passwords are necessarily a compromise of security.  At least not 
in contrast to TLS certificates (which I personally believe are a great 
technology).

On Thursday 07 September 2006 20:38, Dave Bacher wrote:
> Why not just issue a TLS 1 certificate?
>
> Internet Explorer 2 and later support it.  Netscape Navigator 2 and
> later support it.  All versions of Opera support it.  All versions of
> FireFox support it.  All versions of Safari support it.  In fact, the
> vast majority of libraries and user agents that support TLS or even SSL
> websites also support TLS 1 client certificates.
>
> When you issue the certificate, most browsers offer a convenient way to
> send it to the client.  It is installed into the local certificate
> store, or potentially a hardware device such as a smart card.  Later,
> the user authenticates to the user agent, and then is given the option
> of providing the certificate to a site that asks for it.  You can either
> issue a certificate specifically for your site, or you can have them go
> get a (freely available, in at least some cases) client certificate from
> a vendor like VeriSign.  These are typically called "e-mail signing
> certificates" or "digital ID's" by the companies that sell them.
>
> There are a couple big benefits here.  First, you are using an existing
> user agent feature, that every user agent is likely to support.  So you
> just have to talk the user through installing the certificate into IE.
>
> Secondly, web server side, it is a radio button in IIS 4 or later (not
> sure about earlier versions), or a single line in Apache to enable the
> feature.
>
> Thirdly, if the ID becomes compromised, you can issue a revoke request,
> and issue a new ID.  This means the certificate that you issued before
> immediately becomes invalid, and so if the user loses the certificate or
> has it stollen, it takes no effort.
>
> Fourthly, if the computer has a smart card reader (about USD $20) and a
> smart card, the certificate can be installed onto the smart card.  If
> this is done, then the user must provide a valid PIN in conjunction with
> the physical card in order to send data using the identities installed
> onto the card.  This adds a physical layer of security that is not
> possible with a name/password system.
>
> And the worse problem than the number of systems using user id/password
> on a form to authenticate (and not at least using digest) is that many
> of these don't use TLS, and so the password is sent plain text or plain
> text equivalent across the network.  Additionally, many of these systems
> send the username and password pair by e-mail, which means not only is
> the user name and password sent across the internet, but also that it is
> stored in one or more well known locations on the user's computer for at
> least some period of time.  Since most operating systems don't provide
> any mechanism to lock down a directory so that only one module or
> application can access it, and since the most protection most user
> agents offer to e-mail files is the non-protection of a randomly
> generated file name, this is actually the worst part of the security risk.
>
> Failing TLS, most servers (including IIS and Apache) and user agents
> support Kerberos, NTLM and a host of other options, and there are
> several publicly available specifications for what is called "Federated
> Identity."  The problem with all of these is that various parties have
> interests in pushing their own view of how a federated identity should
> work, usually to further their own goals.
>
> Also, keep in mind that a federated identity system also poses privacy
> risks for the user.  When the user connects to your site, you must
> contact the federation and ask if they are who they say that they are.
> This means the federation knows both who you are, and what site you are
> trying to access.  This is why they aren't popular.
>
> TLS doesn't have that problem, because you retrieve a certificate
> revocation list versus asking if a specific certificate is valid.  All
> that verisign (as an example) knows is that a TLS website asked for a
> revocation list, they don't ever know what user it was who was trying to
> access the site.
>
> The issue with a federated log on is you must log on and log off from
> the federation site.  Sites have to check with that site to see if your
> token is valid or not, so any token based authentication inherently
> compromises your privacy (at least potentially).
>
> Anders Rundgren wrote:
> > Dear all,
> > As you probably have noticed, practically every site offers a login.for
> > their members, customers, citizens etc. etc.
> >
> > There are two problems here.
> > 1.   User-id/password management has become a real nuisance. Once this
> > was an issue for computer professionals only, now it affects everyone
> > from children to grandma.
> >
> > 2. There are other and better authentication methods available that
> > become hard to migrate to without making life hard for end-users by
> > asking them to use another login method.  The site has no way of
> > detecting the user's options.
> >
> > It appears, that it may be possible to add some kind of
> > negotiation/option elements at the HTML level, that if supported by the
> > underlying system could offer a standardized and potentially more
> > powerful version of the password caches or external login form "hijacker
> > software" that we currently use. Tentative functionality for the AHE
> > (Authentication Helper Extension):
> >
> > - Find out if the AHE is installed/available
> >
> > - If the AHE is available, find out if the site in question is in the
> > list
> >
> > - If in the list, put out a dialog box giving the user an option to
> > login, decline or manually enter login information.
> >
> > - If the site so requests, the user's authentication options (in case
> > form based authentication was used) can be transferred during login,
> > giving the site an option to ask/require the user to upgrade their
> > authentication.  This could involve anything from digest-authentication
> > to certificates.  The latter current lacks a decent provision method but
> > there is some work going on in this area as well.  MS CardSpaces is also
> > an option.
> >
> > - The authentication stuff would be possible to store in an USB token or
> >   even better in a mobile phone.  This is of course outside of HTML5
> >   but will be natural to support within 3-5 years from now.
> >
> > - The scheme would (if properly implemented) be able to thwart phishing
> >   since a user-id/password (or other auth solution) could be tied to a
> >   SSL root + host name (or even better host domain).
> >
> > In essence the desired result is a portable (mobile) multi-site
> > authentication support mechanism that should not only make the web
> > easier, but also long-term considerably more secure.
> >
> > Other Options?
> > ==========
> > The other option is addressing this problem at the transport level but I
> > think form-based authentication is a better entrance point since it is
> > already in place. There is no problem [at all] of having a mechanism [in
> > the proposed scheme] that switches from form-based authentication to
> > transport-level authentication like using TLS-client-certificates, while
> > the opposite is impossible.
> >
> > Sincerely
> > Anders Rundgren

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/



From ben at benmeadowcroft.com  Fri Sep  8 16:00:01 2006
From: ben at benmeadowcroft.com (Ben Meadowcroft)
Date: Sat, 9 Sep 2006 00:00:01 +0100
Subject: [whatwg] HTLM5 - Addressing the Password Craze?
In-Reply-To: <200609080245.31869.staikos@kde.org>
Message-ID: <008701c6d39a$87f39630$0202a8c0@BensPC>



> -----Original Message-----
> From: George Staikos
> I would like to add a few more points here.
> 
> 2) Certificates are more easily stolen than passwords unless 
> the certificates 
> have passwords on them.  Then, well, we are using passwords again.  
> Certificates have lost most of their value by this point I think.

But you usually can't get someones certificate by offering a mars bar on
the street...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3088 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20060909/d8dbb14a/attachment.bin>

From anders.rundgren at telia.com  Fri Sep  8 23:41:22 2006
From: anders.rundgren at telia.com (Anders Rundgren)
Date: Sat, 9 Sep 2006 08:41:22 +0200
Subject: [whatwg] Certificates & Browsers. Was:] HTML5 - Addressing the
	Password Craze?
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v><BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de><005f01c6d0cd$e9fb2020$82c5a8c0@arport2v><5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com><44FE07E0.9080308@earthlink.net><op.tfgok4kfwxe0ny@widsith.local>	<005101c6d1e5$f1558ef0$82c5a8c0@arport2v><004901c6d245$2c65e710$82c5a8c0@arport2v>
	<BAY107-DAV151583511E2D4BFA7DAEDDC6370@phx.gbl>
Message-ID: <005101c6d3da$f735b060$82c5a8c0@arport2v>

Hi David,
Thank you for your elaborate replay although you did not really
comment on my proposal but rather proposed something else.

>Why not just issue a TLS 1 certificate?

I agree with all you things you say about this technology but let me
begin with another, for the WHATWG applicable comment:

==================================================
  The "standards" for PKI provisioning using browsers are in a real mess.
  Xenroll, KeyGen and a JavaScript CRMF do not really make this
  part as simple as it must be in order to challenge passwords.
==================================================

Anyway, my proposal was about offering a "migration path" to other
authentication schemes, as well as improving the current de-facto standard.

Regarding certificates: the provisioning, mobility and pretty proprietary
card schemes (like no preinstalled drivers in Windows) will make this
transition period rather long.  That none of the browser vendors support
digital signatures (in a reasonable way), is another reason why PKI
deployment is hampered.

Personally, I believe PKI will stay marginal [*] until you can keep your IDs
in a mobile phone.  The US PIV card (to take an example), only allows
you to keep a single Federal ID which is not particularly useful for the
Internet where you will continue to have multiple and mostly entirely
independent IDs.

thanx
Anders

*] There are 10M+ of citizens certificates in Europe, but you cannot
use them at particularly many places due to the problems cited.

////
Internet Explorer 2 and later support it.  Netscape Navigator 2 and 
later support it.  All versions of Opera support it.  All versions of 
FireFox support it.  All versions of Safari support it.  In fact, the 
vast majority of libraries and user agents that support TLS or even SSL 
websites also support TLS 1 client certificates.

When you issue the certificate, most browsers offer a convenient way to 
send it to the client.  It is installed into the local certificate 
store, or potentially a hardware device such as a smart card.  Later, 
the user authenticates to the user agent, and then is given the option 
of providing the certificate to a site that asks for it.  You can either 
issue a certificate specifically for your site, or you can have them go 
get a (freely available, in at least some cases) client certificate from 
a vendor like VeriSign.  These are typically called "e-mail signing 
certificates" or "digital ID's" by the companies that sell them.

There are a couple big benefits here.  First, you are using an existing 
user agent feature, that every user agent is likely to support.  So you 
just have to talk the user through installing the certificate into IE.

Secondly, web server side, it is a radio button in IIS 4 or later (not 
sure about earlier versions), or a single line in Apache to enable the 
feature.

Thirdly, if the ID becomes compromised, you can issue a revoke request, 
and issue a new ID.  This means the certificate that you issued before 
immediately becomes invalid, and so if the user loses the certificate or 
has it stollen, it takes no effort.

Fourthly, if the computer has a smart card reader (about USD $20) and a 
smart card, the certificate can be installed onto the smart card.  If 
this is done, then the user must provide a valid PIN in conjunction with 
the physical card in order to send data using the identities installed 
onto the card.  This adds a physical layer of security that is not 
possible with a name/password system.

And the worse problem than the number of systems using user id/password 
on a form to authenticate (and not at least using digest) is that many 
of these don't use TLS, and so the password is sent plain text or plain 
text equivalent across the network.  Additionally, many of these systems 
send the username and password pair by e-mail, which means not only is 
the user name and password sent across the internet, but also that it is 
stored in one or more well known locations on the user's computer for at 
least some period of time.  Since most operating systems don't provide 
any mechanism to lock down a directory so that only one module or 
application can access it, and since the most protection most user 
agents offer to e-mail files is the non-protection of a randomly 
generated file name, this is actually the worst part of the security risk.

Failing TLS, most servers (including IIS and Apache) and user agents 
support Kerberos, NTLM and a host of other options, and there are 
several publicly available specifications for what is called "Federated 
Identity."  The problem with all of these is that various parties have 
interests in pushing their own view of how a federated identity should 
work, usually to further their own goals.

Also, keep in mind that a federated identity system also poses privacy 
risks for the user.  When the user connects to your site, you must 
contact the federation and ask if they are who they say that they are.  
This means the federation knows both who you are, and what site you are 
trying to access.  This is why they aren't popular.

TLS doesn't have that problem, because you retrieve a certificate 
revocation list versus asking if a specific certificate is valid.  All 
that verisign (as an example) knows is that a TLS website asked for a 
revocation list, they don't ever know what user it was who was trying to 
access the site.

The issue with a federated log on is you must log on and log off from 
the federation site.  Sites have to check with that site to see if your 
token is valid or not, so any token based authentication inherently 
compromises your privacy (at least potentially).

Anders Rundgren wrote:
> Dear all,
> As you probably have noticed, practically every site offers a login.for their
> members, customers, citizens etc. etc.
>
> There are two problems here.
> 1.   User-id/password management has become a real nuisance. Once this was
> an issue for computer professionals only, now it affects everyone from children
> to grandma.
>
> 2. There are other and better authentication methods available that become hard
> to migrate to without making life hard for end-users by asking them to use another
> login method.  The site has no way of detecting the user's options.
>
> It appears, that it may be possible to add some kind of negotiation/option
> elements at the HTML level, that if supported by the underlying system could
> offer a standardized and potentially more powerful version of the password
> caches or external login form "hijacker software" that we currently use. 
> Tentative functionality for the AHE (Authentication Helper Extension):
>
> - Find out if the AHE is installed/available
>
> - If the AHE is available, find out if the site in question is in the list
>
> - If in the list, put out a dialog box giving the user an option to login, decline
>   or manually enter login information. 
>
> - If the site so requests, the user's authentication options (in case form based
>   authentication was used) can be transferred during login, giving the site an
>   option to ask/require the user to upgrade their authentication.  This could
>   involve anything from digest-authentication to certificates.  The latter
>   current lacks a decent provision method but there is some work 
>   going on in this area as well.  MS CardSpaces is also an option.
>
> - The authentication stuff would be possible to store in an USB token or
>   even better in a mobile phone.  This is of course outside of HTML5
>   but will be natural to support within 3-5 years from now.
>
> - The scheme would (if properly implemented) be able to thwart phishing
>   since a user-id/password (or other auth solution) could be tied to a
>   SSL root + host name (or even better host domain).
>
> In essence the desired result is a portable (mobile) multi-site authentication
>  support mechanism that should not only make the web easier, but also
> long-term considerably more secure.  
>
> Other Options?
> ==========
> The other option is addressing this problem at the transport level but I think
> form-based authentication is a better entrance point since it is already in place.
> There is no problem [at all] of having a mechanism [in the proposed scheme]
> that switches from form-based authentication to transport-level authentication
> like using TLS-client-certificates, while the opposite is impossible.
>
> Sincerely
> Anders Rundgren
>
>
>
>
>   







From staikos at kde.org  Fri Sep  8 18:35:06 2006
From: staikos at kde.org (George Staikos)
Date: Fri, 8 Sep 2006 21:35:06 -0400
Subject: [whatwg] HTLM5 - Addressing the Password Craze?
In-Reply-To: <008701c6d39a$87f39630$0202a8c0@BensPC>
References: <008701c6d39a$87f39630$0202a8c0@BensPC>
Message-ID: <200609082135.06437.staikos@kde.org>

On Friday 08 September 2006 19:00, Ben Meadowcroft wrote:
> > -----Original Message-----
> > From: George Staikos
> > I would like to add a few more points here.
> >
> > 2) Certificates are more easily stolen than passwords unless
> > the certificates
> > have passwords on them.  Then, well, we are using passwords again.
> > Certificates have lost most of their value by this point I think.
>
> But you usually can't get someones certificate by offering a mars bar on
> the street...

   Do you have evidence that this is any different than the password case?

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/



From fora at annevankesteren.nl  Sat Sep  9 09:00:15 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Sat, 09 Sep 2006 18:00:15 +0200
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <Pine.LNX.4.64.0609081735250.5305@holly>
References: <Pine.LNX.4.64.0609081735250.5305@holly>
Message-ID: <op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>

On Fri, 08 Sep 2006 18:40:34 +0200, Dave Raggett <dsr at w3.org> wrote:
> p.s. implementing the output element would be a lot cleaner if more  
> browsers supported the /> syntax for empty elements that aren't part of  
> traditional HTML. IE already does so, but Firefox and Opera do not.  
> Firefox is even worse as it coerces the tag name to upper case when you  
> inspect the DOM node it creates! Opera and Firefox also differ over the  
> amount of whitespace text nodes that are set as the content on unknown  
> elements. IE has its own weird worts, although strangely, it works  
> rather nicely for non-html markup in XML namespaces. IE therefore  
> encourages the use of XML namespaces for mixed markup when delivered as  
> text/html.

You sure IE only does this for <foo/> and not also for <foo>? It's my  
understand they are treated as being identical in every single browser.  
Whether or not such an element is treated as empty varies from browser to  
browser.

Converting the node name to uppercase also seems like the right thing to  
do for text/html documents although HTML5 might change bits of that...


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From dsr at w3.org  Sun Sep 10 03:17:19 2006
From: dsr at w3.org (Dave Raggett)
Date: Sun, 10 Sep 2006 11:17:19 +0100 (BST)
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>
References: <Pine.LNX.4.64.0609081735250.5305@holly>
	<op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>
Message-ID: <Pine.LNX.4.64.0609101045340.5363@holly>

On Sat, 9 Sep 2006, Anne van Kesteren wrote:

> On Fri, 08 Sep 2006 18:40:34 +0200, Dave Raggett <dsr at w3.org> wrote:
>> p.s. implementing the output element would be a lot cleaner if 
>> more browsers supported the /> syntax for empty elements that 
>> aren't part of traditional HTML. IE already does so, but Firefox 
>> and Opera do not. Firefox is even worse as it coerces the tag 
>> name to upper case when you inspect the DOM node it creates! 
>> Opera and Firefox also differ over the amount of whitespace text 
>> nodes that are set as the content on unknown elements. IE has its 
>> own weird worts, although strangely, it works rather nicely for 
>> non-html markup in XML namespaces. IE therefore encourages the 
>> use of XML namespaces for mixed markup when delivered as 
>> text/html.
>
> You sure IE only does this for <foo/> and not also for <foo>? It's 
> my understand they are treated as being identical in every single 
> browser. Whether or not such an element is treated as empty varies 
> from browser to browser.

For traditional HTML elements, IE uses its built-in knowledge of
their content model, along with rules for dealing with malformed
HTML markup.

For other elements the behavior depends upon whether the tag
has a namespace prefix or not.

If the tag doesn't have an XML namespace prefix, then it is
inserted into the DOM as an empty upper case element.

   <foo>     nodeName = "FOO"
   </foo>    nodeName = "/FOO"
   <foo/>    nodeName = "FOO"

The same is true if you define the XML namespace with the
xmlns attribute e.g.

   <foo xmlns="http://example.com/ns"/>  nodeName="FOO"

BUT if you use a tag with a previously defined XML namespace
then things are different:

   <f:foo>hello world</f:foo>

is parsed as a foo element with a text node "hello world" as its
content. The case for the element's tag name is preserved.

if the namespace prefix isn't previously declared then you get:

   <f:foo>    nodeName = "F:FOO"
   </f:foo>   nodeName = "/F:FOO"

However, the namespace declaration can leave the URI empty, e.g.

  <html xmlns:f="">

is sufficient for IE to avoid giving <f:foo> the empty uppercase
treatment.

It isn't sufficient to define the namespace on the element itself
as in the following example:

   <g:fred xmlns:g="">smith</g:fred>

which gets the uppercase empty element treatment. To avoid
that, you need to declare the namespace on the html start tag.

Elements with a declared XML namespace prefix can be styled
with CSS.

Note that my tests were done using a script to walk the DOM
tree and display the results in an alert box.

With a knowledge of the above behavior, web page scripts can
be written clean up the DOM, e.g. placing the tags into the
HTML namespace with a dynamically defined prefix, and fixing
up the content. It's not a show stopper.

> Converting the node name to uppercase also seems like the right 
> thing to do for text/html documents although HTML5 might change 
> bits of that...

Perhaps.

Another difference between IE and Opera is that Opera includes
the prefix as part of the node name for elements with a previously
declared XML namespace.

None of this is insurmountable by a determined scripter, but we
might perhaps try and aim for closer alignment amongst different 
browsers that is currently the case. I am not advocating that
Opera follows IE's upper case/empty element weirdness, rather
that Opera treat <foo/> as an empty element.

  Dave Raggett <dsr at w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)


From hasather at gmail.com  Sun Sep 10 03:35:25 2006
From: hasather at gmail.com (=?ISO-8859-1?Q?David_H=E5s=E4ther?=)
Date: Sun, 10 Sep 2006 12:35:25 +0200
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <Pine.LNX.4.64.0609101045340.5363@holly>
References: <Pine.LNX.4.64.0609081735250.5305@holly>	<op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.64.0609101045340.5363@holly>
Message-ID: <4503EA6D.6020408@gmail.com>

On 2006-09-10 12:17, Dave Raggett wrote:
> On Sat, 9 Sep 2006, Anne van Kesteren wrote:
>> You sure IE only does this for <foo/> and not also for <foo>? It's my
>> understand they are treated as being identical in every single
>> browser. Whether or not such an element is treated as empty varies
>> from browser to browser.
> 
> For traditional HTML elements, IE uses its built-in knowledge of
> their content model, along with rules for dealing with malformed
> HTML markup.
> 
> For other elements the behavior depends upon whether the tag
> has a namespace prefix or not.
> 
> If the tag doesn't have an XML namespace prefix, then it is
> inserted into the DOM as an empty upper case element.
> 
>   <foo>     nodeName = "FOO"
>   </foo>    nodeName = "/FOO"
>   <foo/>    nodeName = "FOO"

What does tags have to do with the DOM?

-- 
David H?s?ther


From monterro2004 at tiscali.co.uk  Sun Sep 10 03:41:51 2006
From: monterro2004 at tiscali.co.uk (Francisco Monteiro)
Date: Sun, 10 Sep 2006 11:41:51 +0100
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <4503EA6D.6020408@gmail.com>
Message-ID: <021701c6d4c5$ba2c5070$0500a8c0@computername>

>What does tags have to do with the DOM?

Exactly, is this thread becoming a Opera marketing ploy?

Francisco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3210 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20060910/0f00d4e4/attachment.bin>

From fora at annevankesteren.nl  Sun Sep 10 03:47:42 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Sun, 10 Sep 2006 12:47:42 +0200
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <021701c6d4c5$ba2c5070$0500a8c0@computername>
References: <021701c6d4c5$ba2c5070$0500a8c0@computername>
Message-ID: <op.tfnr9s06aw9dld@id-c0020.oslo.opera.com>

On Sun, 10 Sep 2006 12:41:51 +0200, Francisco Monteiro  
<monterro2004 at tiscali.co.uk> wrote:
>> What does tags have to do with the DOM?
>
> Exactly, is this thread becoming a Opera marketing ploy?

?


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From lachlan.hunt at lachy.id.au  Sun Sep 10 03:47:47 2006
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Sun, 10 Sep 2006 20:47:47 +1000
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <Pine.LNX.4.64.0609101045340.5363@holly>
References: <Pine.LNX.4.64.0609081735250.5305@holly>	<op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.64.0609101045340.5363@holly>
Message-ID: <4503ED53.4070304@lachy.id.au>

Dave Raggett wrote:
> For traditional HTML elements, IE uses its built-in knowledge of
> their content model, along with rules for dealing with malformed
> HTML markup.
> 
> For other elements the behavior depends upon whether the tag
> has a namespace prefix or not.
> 
> If the tag doesn't have an XML namespace prefix, then it is
> inserted into the DOM as an empty upper case element.
> 
>   <foo>     nodeName = "FOO"
>   </foo>    nodeName = "/FOO"
>   <foo/>    nodeName = "FOO"
> 
> The same is true if you define the XML namespace with the
> xmlns attribute e.g.
> 
>   <foo xmlns="http://example.com/ns"/>  nodeName="FOO"

So far, that's correct.

> BUT if you use a tag with a previously defined XML namespace
> then things are different:
> 
>   <f:foo>hello world</f:foo>
> 
> is parsed as a foo element with a text node "hello world" as its
> content. The case for the element's tag name is preserved.


My tests show that the namespace does not have to be previously 
decalred, the results (as far as the tagName is concerned) are the same 
either way.

> if the namespace prefix isn't previously declared then you get:
> 
>   <f:foo>    nodeName = "F:FOO"
>   </f:foo>   nodeName = "/F:FOO"

Please publish a test case demonstrating this.  My tests show the same 
result is achieved regardless of whether the namespace is declared.

> It isn't sufficient to define the namespace on the element itself
> as in the following example:
> 
>   <g:fred xmlns:g="">smith</g:fred>
> 
> which gets the uppercase empty element treatment.

That's not what I get either.  My tests showed the tag name in lowercase.

> Elements with a declared XML namespace prefix can be styled
> with CSS.

How can the be styled in a way that is affected by the namespace 
declaration?  My tests show that the only way to style such an element 
is like the following and it will apply regardless of whether its 
namespace is declared.

f\:foo { background: green; }

<f:foo>test</f:foo>

> Note that my tests were done using a script to walk the DOM
> tree and display the results in an alert box.

My tests were done using your supplied sample markup and the Live DOM 
Viewer, which uses a similar approach.

http://software.hixie.ch/utilities/js/live-dom-viewer/

> None of this is insurmountable by a determined scripter, but we
> might perhaps try and aim for closer alignment amongst different 
> browsers that is currently the case. I am not advocating that
> Opera follows IE's upper case/empty element weirdness, rather
> that Opera treat <foo/> as an empty element.

How about we just forget about the crazy notion of introducing 
pseudo-XML syntax and handling into HTML.  If XHTML really is the future 
(as many people, including myself, have claimed), then we really don't 
want to destroy it by allowing it to be used and abused like HTML?the 
very thing it was designed to replace!

Please provide test cases demonstrating every result you obtained, 
especially where my tests have given different results.

-- 
Lachlan Hunt
http://lachy.id.au/


From lachlan.hunt at lachy.id.au  Sun Sep 10 03:50:58 2006
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Sun, 10 Sep 2006 20:50:58 +1000
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <021701c6d4c5$ba2c5070$0500a8c0@computername>
References: <021701c6d4c5$ba2c5070$0500a8c0@computername>
Message-ID: <4503EE12.1070509@lachy.id.au>

Francisco Monteiro wrote:
>> What does tags have to do with the DOM?

We're talking about the DOM that IE produces when given specific markup. 
  It has everything to do with the DOM!

> Exactly, is this thread becoming a Opera marketing ploy?

What the...?

-- 
Lachlan Hunt
http://lachy.id.au/


From hasather at gmail.com  Sun Sep 10 03:56:35 2006
From: hasather at gmail.com (=?UTF-8?B?RGF2aWQgSMOlc8OkdGhlcg==?=)
Date: Sun, 10 Sep 2006 12:56:35 +0200
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <4503EE12.1070509@lachy.id.au>
References: <021701c6d4c5$ba2c5070$0500a8c0@computername>
	<4503EE12.1070509@lachy.id.au>
Message-ID: <4503EF63.3060403@gmail.com>

On 2006-09-10 12:50, Lachlan Hunt wrote:
> Francisco Monteiro wrote:
>>> What does tags have to do with the DOM?
> 
> We're talking about the DOM that IE produces when given specific markup.

Sorry for not following the whole discussion.

>> Exactly, is this thread becoming a Opera marketing ploy?
> 
> What the...?

Exactly.

-- 
David H?s?ther


From dsr at w3.org  Sun Sep 10 05:19:02 2006
From: dsr at w3.org (Dave Raggett)
Date: Sun, 10 Sep 2006 13:19:02 +0100 (BST)
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <4503ED53.4070304@lachy.id.au>
References: <Pine.LNX.4.64.0609081735250.5305@holly>
	<op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.64.0609101045340.5363@holly> <4503ED53.4070304@lachy.id.au>
Message-ID: <Pine.LNX.4.64.0609101241030.5348@holly>

You can reproduce my tests by pointing your browser at:

   http://people.w3.org/~dsr/dom/test.html

This will display an alert box with a representation of the
DOM tree showing element and text nodes but not attributes.
The string value from the node's nodeName property are shown
within single quotemarks.

You can then use view source to look at the source markup. Let
me know if you want to create some more tests. For example, it's 
possible that the results will vary according to whether IE is in 
quirks mode or not.

With regards to the CSS tests:

On IE the only word to be highlighted is the second "jones".
The CSS rules in the style sheet are not applied by IE to the
first and third instances of the fred element.

On Opera and Firefox, all three instances are higlighted.

With regards to the parsing tests, I presume that Opera shows
output in uppercase because it thinks it is part of the
predefined html tag set as Anne suggested.

  Dave Raggett <dsr at w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)


From danbri at danbri.org  Sun Sep 10 05:35:09 2006
From: danbri at danbri.org (Dan Brickley)
Date: Sun, 10 Sep 2006 13:35:09 +0100
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <4503EF63.3060403@gmail.com>
References: <021701c6d4c5$ba2c5070$0500a8c0@computername>	<4503EE12.1070509@lachy.id.au>
	<4503EF63.3060403@gmail.com>
Message-ID: <4504067D.5060402@danbri.org>

David H?s?ther wrote:
> On 2006-09-10 12:50, Lachlan Hunt wrote:
>> Francisco Monteiro wrote:
>>>> What does tags have to do with the DOM?
>> We're talking about the DOM that IE produces when given specific markup.
> 
> Sorry for not following the whole discussion.
> 
>>> Exactly, is this thread becoming a Opera marketing ploy?
>> What the...?
> 
> Exactly.

While we're at it... I was wondering what's best: Windows or MacOS X...?

Dan



From fora at annevankesteren.nl  Sun Sep 10 05:34:01 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Sun, 10 Sep 2006 14:34:01 +0200
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <Pine.LNX.4.64.0609101241030.5348@holly>
References: <Pine.LNX.4.64.0609081735250.5305@holly>
	<op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.64.0609101045340.5363@holly>
	<4503ED53.4070304@lachy.id.au>
	<Pine.LNX.4.64.0609101241030.5348@holly>
Message-ID: <op.tfnw6zpwaw9dld@id-c0020.oslo.opera.com>

On Sun, 10 Sep 2006 14:19:02 +0200, Dave Raggett <dsr at w3.org> wrote:
> You can then use view source to look at the source markup. Let
> me know if you want to create some more tests. For example, it's  
> possible that the results will vary according to whether IE is in quirks  
> mode or not.

It seems you're currently "testing" in quirks mode. I suggest we only look  
at standards mode as that's relevant for the HTML5 parsing section.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From lachlan.hunt at lachy.id.au  Sun Sep 10 06:40:24 2006
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Sun, 10 Sep 2006 23:40:24 +1000
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <Pine.LNX.4.64.0609101241030.5348@holly>
References: <Pine.LNX.4.64.0609081735250.5305@holly>	<op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>	<Pine.LNX.4.64.0609101045340.5363@holly>
	<4503ED53.4070304@lachy.id.au>
	<Pine.LNX.4.64.0609101241030.5348@holly>
Message-ID: <450415C8.5070806@lachy.id.au>

Dave Raggett wrote:
> You can reproduce my tests by pointing your browser at:
> 
>   http://people.w3.org/~dsr/dom/test.html

OK, I have the discovered the reason for the discrepancy in our results. 
  Apparently IE handles exactly the same markup differently depending 
upon how it is added to the page.

If you load my test case [1] in IE, tests A through E are styled, but 
test F isn't.  This shows the following:

IE will only allow styling of elements with namespace prefixes that have 
been either explicitly or implicitly declared.

There are two ways to explicitly declare a namespace in IE:
1. <html xmlns:foo="http://example.org/foo">
2. <?xml:namespace prefix = foo ns = "http://example.org/foo" />

In both cases, the URI may be omitted.

When a "Custom Tag" (the name Microsoft have given elements with 
namespace prefixes in HTML) is added using either innerHTML or 
document.write(), the PI that declares the namespace will be implicitly 
generated using the prefix but with no actual namespace name.

This explains why I was getting different results using the Live DOM 
Viewer because it uses innerHTML to copy the markup from the text box to 
the rendering area.  That means that IE was implicitly declaring the 
namespace of all Custom Tags in my tests.

[1] http://lachy.id.au/dev/2006/09/custom-tags

-- 
Lachlan Hunt
http://lachy.id.au/


From dsr at w3.org  Sun Sep 10 09:29:02 2006
From: dsr at w3.org (Dave Raggett)
Date: Sun, 10 Sep 2006 17:29:02 +0100 (BST)
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <op.tfnw6zpwaw9dld@id-c0020.oslo.opera.com>
References: <Pine.LNX.4.64.0609081735250.5305@holly>
	<op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.64.0609101045340.5363@holly> <4503ED53.4070304@lachy.id.au>
	<Pine.LNX.4.64.0609101241030.5348@holly>
	<op.tfnw6zpwaw9dld@id-c0020.oslo.opera.com>
Message-ID: <Pine.LNX.4.64.0609101725310.5348@holly>

On Sun, 10 Sep 2006, Anne van Kesteren wrote:

> On Sun, 10 Sep 2006 14:19:02 +0200, Dave Raggett <dsr at w3.org> wrote:
>> You can then use view source to look at the source markup. Let me 
>> know if you want to create some more tests. For example, it's 
>> possible that the results will vary according to whether IE is in 
>> quirks mode or not.
>
> It seems you're currently "testing" in quirks mode. I suggest we 
> only look at standards mode as that's relevant for the HTML5 
> parsing section.

Well I tried removing the XML declaration and adding the doctype
for XHTML, but it doesn't seem to have made any difference.

  http://people.w3.org/~dsr/dom/test2.html

p.s. I was using the info on quirks mode at:

           http://en.wikipedia.org/wiki/Quirks_mode

  Dave Raggett <dsr at w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)



From fora at annevankesteren.nl  Sun Sep 10 09:49:52 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Sun, 10 Sep 2006 18:49:52 +0200
Subject: [whatwg] Editorial: parsing section
Message-ID: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>

When you have phrases like 'Change the insertion mode to "in select".' it
would be nice if "in select" was a pointer to the relevant section.
Currently "insertion mode" is a pointer and that's hardly useful.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From fora at annevankesteren.nl  Tue Sep 12 01:06:20 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Tue, 12 Sep 2006 10:06:20 +0200
Subject: [whatwg] Fwd: Re: [xhtml-role] Extensibility of XHTML 1 and XHTML
	1.1 (PR#9627)
In-Reply-To: <200609120801.k8C81Pm1023273@htmlwg.mn.aptest.com>
References: <200609120801.k8C81Pm1023273@htmlwg.mn.aptest.com>
Message-ID: <op.tfq94ur2aw9dld@id-c0020.oslo.opera.com>

Might be of interest...


------- Forwarded message -------
From: "Shane McCarron" <voyager-issues at mn.aptest.com>
To: karl at w3.org
Cc: www-html-editor at w3.org
Subject: Re: [xhtml-role] Extensibility of XHTML 1 and XHTML 1.1 (PR#9627)
Date: Tue, 12 Sep 2006 10:01:25 +0200


XHTML2 will be using the same namespace as XHTML1, and there will not be
two
modules.



-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From lachlan.hunt at lachy.id.au  Tue Sep 12 04:29:50 2006
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Tue, 12 Sep 2006 21:29:50 +1000
Subject: [whatwg] Fwd: Re: [xhtml-role] Extensibility of XHTML 1 and
 XHTML 1.1 (PR#9627)
In-Reply-To: <op.tfq94ur2aw9dld@id-c0020.oslo.opera.com>
References: <200609120801.k8C81Pm1023273@htmlwg.mn.aptest.com>
	<op.tfq94ur2aw9dld@id-c0020.oslo.opera.com>
Message-ID: <45069A2E.9060008@lachy.id.au>

Anne van Kesteren forwarded this from Shane McCarron:
> XHTML2 will be using the same namespace as XHTML1, and there will not be
> two modules.

Great news!  I wonder how open the HTML WG will be with regards to 
working with the WHATWG and HTML 5, especially now that the 2 specs will 
share the same namespace.  If we don't resolve the incompatibilities, 
one of the specs will simply be doomed to failure.

-- 
Lachlan Hunt
http://lachy.id.au/


From ian at hixie.ch  Tue Sep 12 06:51:53 2006
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 Sep 2006 06:51:53 -0700
Subject: [whatwg] Fwd: Re: [xhtml-role] Extensibility of XHTML 1 and
	XHTML 1.1 (PR#9627)
In-Reply-To: <45069A2E.9060008@lachy.id.au>
References: <200609120801.k8C81Pm1023273@htmlwg.mn.aptest.com>
	<op.tfq94ur2aw9dld@id-c0020.oslo.opera.com>
	<45069A2E.9060008@lachy.id.au>
Message-ID: <403d38e20609120651p6bad3ecbqa333bad833738f1a@mail.gmail.com>

Anne van Kesteren forwarded this from Shane McCarron:
> XHTML2 will be using the same namespace as XHTML1, and there will not be
> two modules.

This has been an "issue" in the XHTML2 draft for some time:
http://www.w3.org/TR/xhtml2/conformance.html#s_conform_issue_4


On 9/12/06, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> Great news!  I wonder how open the HTML WG will be with regards to
> working with the WHATWG and HTML 5, especially now that the 2 specs will
> share the same namespace.  If we don't resolve the incompatibilities,
> one of the specs will simply be doomed to failure.

I would be more concerned about how they are intending on making
XHTML2 compatible with XHTML1 than with the WHATWG work. For example,
XHTML2's <input> element has basically completely different semantics
than XHTML1's. Even simple elements like <img> and <q> are
incompatible across the two versions, in the current draft.

-- 
Ian Hickson


From mattraymond at earthlink.net  Tue Sep 12 08:14:26 2006
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Tue, 12 Sep 2006 11:14:26 -0400
Subject: [whatwg] Fwd: Re: [xhtml-role] Extensibility of XHTML 1
 and	XHTML 1.1 (PR#9627)
In-Reply-To: <403d38e20609120651p6bad3ecbqa333bad833738f1a@mail.gmail.com>
References: <200609120801.k8C81Pm1023273@htmlwg.mn.aptest.com>	<op.tfq94ur2aw9dld@id-c0020.oslo.opera.com>	<45069A2E.9060008@lachy.id.au>
	<403d38e20609120651p6bad3ecbqa333bad833738f1a@mail.gmail.com>
Message-ID: <4506CED2.7040202@earthlink.net>

Ian Hickson wrote:
> I would be more concerned about how they are intending on making
> XHTML2 compatible with XHTML1 than with the WHATWG work.

   Hopefully they won't revive the |version| attribute, as John M. Boyer
has suggested.

> For example,
> XHTML2's <input> element has basically completely different semantics
> than XHTML1's.

   That's because XHTML 2.0 simply reuses XForms in the XHTML namespace,
so the HTML WG isn't the place to debate this, unfortunately. You really
need to catch up on the public-appformats mailing list when you have the
opportunity. There's lively debate about <input>, XForms and WF2 there.
(Should we be CCing those messages to this mailing list?)

> Even simple elements like <img> and <q> are
> incompatible across the two versions, in the current draft.

http://www.w3.org/TR/xhtml2/mod-image.html#edef_image_img

| The img element is a holder for embedding attributes such as src.
| Since these attributes may be applied to any element, the img element
| is not strictly necessary, but is included to ease the transition to
| XHTML2.

   Why are they even including it then, especially since <object> has
the same content model and supports images?


http://www.w3.org/TR/xhtml2/mod-text.html#edef_text_q

| Visual user agents must not by default add delimiting quotation marks
| (as was the case for the q element in earlier versions of XHTML and
| HTML). It is the responsibility of the document author to add any
| required quotation marks, either directly in the text, or via a style
| sheet.

   So what's the use of <q> in XHTML 2.0? If there's no difference
between the default styling and standard text, what's the web author's
motivation to use it?

   Furthermore, putting quotation characters in the markup is useless if
you want to quote a quote. In HTML and XHTML 1.x, you could simply nest
<q> elements, but that's not the case with XHTML 2.0.

   Also, why get rid of <acronym>? It's more widely supported than
<abbr>. Granted, it's sort of a subset of <abbr>, but acronyms are
common enough to justify their own element.

   The <l> and <br> elements might be able to coexist, so long as we
specify them correctly. For instance, <l> should never contain a <br>.
Would <l> be styled as block, though, rather than inline? What happens
if it runs over?

   Well, enough for now...


From ian at hixie.ch  Tue Sep 12 08:18:27 2006
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 Sep 2006 08:18:27 -0700
Subject: [whatwg] Fwd: Re: [xhtml-role] Extensibility of XHTML 1 and
	XHTML 1.1 (PR#9627)
In-Reply-To: <4506CED2.7040202@earthlink.net>
References: <200609120801.k8C81Pm1023273@htmlwg.mn.aptest.com>
	<op.tfq94ur2aw9dld@id-c0020.oslo.opera.com>
	<45069A2E.9060008@lachy.id.au>
	<403d38e20609120651p6bad3ecbqa333bad833738f1a@mail.gmail.com>
	<4506CED2.7040202@earthlink.net>
Message-ID: <403d38e20609120818g1d325bf0oda09f7b52f60aa9b@mail.gmail.com>

On 9/12/06, Matthew Raymond <mattraymond at earthlink.net> wrote:
> >
> > For example,
> > XHTML2's <input> element has basically completely different semantics
> > than XHTML1's.
>
> That's because XHTML 2.0 simply reuses XForms in the XHTML namespace,
> so the HTML WG isn't the place to debate this, unfortunately.

Yeah.

WHATWG isn't really the place to debate this either, I guess. Let's
leave this problem up to the W3C to deal with.

(PS. Just one more week of vacation and then I'll be resuming work on
WA1. Hopefully we can get this baby into a feature-complete state
soon.)

-- 
Ian Hickson


From fora at annevankesteren.nl  Tue Sep 12 08:37:17 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Tue, 12 Sep 2006 17:37:17 +0200
Subject: [whatwg] <acronym> (was: Re: Fwd: Re: [xhtml-role] Extensibility of
	XHTML 1 and XHTML 1.1 (PR#9627))
In-Reply-To: <4506CED2.7040202@earthlink.net>
References: <200609120801.k8C81Pm1023273@htmlwg.mn.aptest.com>
	<op.tfq94ur2aw9dld@id-c0020.oslo.opera.com>
	<45069A2E.9060008@lachy.id.au>
	<403d38e20609120651p6bad3ecbqa333bad833738f1a@mail.gmail.com>
	<4506CED2.7040202@earthlink.net>
Message-ID: <op.tfru0fxaaw9dld@id-c0020.oslo.opera.com>

On Tue, 12 Sep 2006 17:14:26 +0200, Matthew Raymond  
<mattraymond at earthlink.net> wrote:
>    Also, why get rid of <acronym>? It's more widely supported than
> <abbr>. Granted, it's sort of a subset of <abbr>, but acronyms are
> common enough to justify their own element.

Actually, I agree with dropping <acronym>. It's just there to confuse  
authors. (HTML5 doesn't include it either.)


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From fora at annevankesteren.nl  Tue Sep 12 08:44:27 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Tue, 12 Sep 2006 17:44:27 +0200
Subject: [whatwg] Fwd: Re: [xhtml-role] Extensibility of XHTML 1 and
	XHTML 1.1 (PR#9627)
In-Reply-To: <403d38e20609120651p6bad3ecbqa333bad833738f1a@mail.gmail.com>
References: <200609120801.k8C81Pm1023273@htmlwg.mn.aptest.com>
	<op.tfq94ur2aw9dld@id-c0020.oslo.opera.com>
	<45069A2E.9060008@lachy.id.au>
	<403d38e20609120651p6bad3ecbqa333bad833738f1a@mail.gmail.com>
Message-ID: <op.tfrvcdd6aw9dld@id-c0020.oslo.opera.com>

On Tue, 12 Sep 2006 15:51:53 +0200, Ian Hickson <ian at hixie.ch> wrote:
> Anne van Kesteren forwarded this from Shane McCarron:
>> XHTML2 will be using the same namespace as XHTML1, and there will not be
>> two modules.
>
> This has been an "issue" in the XHTML2 draft for some time:
> http://www.w3.org/TR/xhtml2/conformance.html#s_conform_issue_4

Yeah, I noticed that. I just thought that was there to please someone as  
it doesn't really seem like an option, as you point in your reply to  
Lachlan... Oh well, should be fun!


> I would be more concerned about how they are intending on making
> XHTML2 compatible with XHTML1 than with the WHATWG work. For example,
> XHTML2's <input> element has basically completely different semantics
> than XHTML1's. Even simple elements like <img> and <q> are
> incompatible across the two versions, in the current draft.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From joao.eiras at gmail.com  Tue Sep 19 16:27:12 2006
From: joao.eiras at gmail.com (Joao Eiras)
Date: Wed, 20 Sep 2006 00:27:12 +0100
Subject: [whatwg] MediaModeAbstractView and changing of media dynamically
Message-ID: <op.tf5ffmvzxl3at9@dragast.mshome.net>

For me, the w3c DOM 2 stylesheets spec always had the gap, which  
MediaModeAbstractView fixes: a variable which holds the current media how  
the page is being rendered.
But there's another small gap. Some UAs (Opera for desktop only to my  
knowledge) can change the current media by displaying a webpage as  
fullscreen (projection) or enabling small screen rendering (handheld). I  
assume future versions will allow Opera to trigger tv mode, for  
development sake. Also any other browsers can change from normal rendering  
(screen) to print preview (print).

The only way for a script to keep track of this variable value, is to set  
an interval, polling the variable.
I don't consider refreshing the page as valid workaround.

So, I suggest the creation of the 'media-change' event, which will fire  
when the UA changes media, having the document as target.
The event object could be an instance of a UIEvent, and have 2 extra  
properties: newMediaMode, and oldMediaMode.


From ian at hixie.ch  Tue Sep 19 16:39:30 2006
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 19 Sep 2006 23:39:30 +0000 (UTC)
Subject: [whatwg] Enhanced data tables
In-Reply-To: <E80F2D4C-45CB-11D9-85F5-000A95AD3972@myrealbox.com>
References: <C5613EDC-30EB-11D9-9F1E-000A957E8988@uk2.net>
	<0BF1DCCA-3135-11D9-ABBD-000A95AD3972@myrealbox.com>
	<Pine.LNX.4.61.0412031701020.20176@dhalsim.dreamhost.com>
	<569C3FA2-4551-11D9-807B-000A957E8988@uk2.net>
	<E80F2D4C-45CB-11D9-85F5-000A95AD3972@myrealbox.com>
Message-ID: <Pine.LNX.4.62.0609192333150.21538@dhalsim.dreamhost.com>

On Sat, 4 Dec 2004, Matthew Thomas wrote:
> On 4 Dec, 2004, at 6:32 AM, Afternoon wrote:
> > On 3 Dec 2004, at 17:18, Ian Hickson wrote:
> > ...
> > > From a practical standpoint the difference between a <table> and a data
> > > grid is that the table's data is all in a DOM content model, whereas the
> > > data grid can be dynamically populated from script, one row at a time, so
> > > that only the displayed portion need be in memory at any one time.
> 
> Could functions be devised to make populating (and depopulating) <table> 
> rows and columns easier than it is now, without inventing a new element 
> for such tables?

Not without further overloading the <table> element. The requirements for 
implementing <table> are already pretty onerous, with custom DOM 
interfaces, at least three rendering models, one of which is not formally 
defined anywhere, the second of which is only poorly defined, peculiar 
parsing requirements, etc.

By having a new element, which can wrap <table>, we can reuse the <table> 
semantics, while still allowing UAs to separate their <table> 
implementation from the new code neatly.

<table> is a very brittle element in terms of implementations -- it's a 
source of many quite complex bugs. Adding more complex code to <table> 
doesn't seem like a good idea.


> > > Another difference is that tables have a legacy of rendering 
> > > semantics which we can't do much about, whereas for the data grid we 
> > > want to be able to use GUI-specific native controls (or 
> > > native-looking controls) which have features such as clickable 
> > > column headers, draggable column separators, etc. Also, datagrids 
> > > are limited to text in each cell (with one icon per row), rows can 
> > > be selected, data can be marked as editable, etc.
> >
> > Indeed, a browser that assumed every <table> was data-bearing and 
> > should have controls displayed would be all but useless.
> 
> That's why I suggested those controls be displayed only for <th> 
> elements, not for every <table>.

I'm not convinced that this would be enough to avoid breaking assumptions 
made by existing Web pages. It also would, as mentioned above, require 
overloading of <table>.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Sep 19 16:45:44 2006
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 19 Sep 2006 23:45:44 +0000 (UTC)
Subject: [whatwg] Web Apps 1.0 - DataGrid
In-Reply-To: <42A9EC1C.7010106@coralbark.net>
References: <42A9EC1C.7010106@coralbark.net>
Message-ID: <Pine.LNX.4.62.0609192340110.21538@dhalsim.dreamhost.com>

On Fri, 10 Jun 2005, Jon Levell wrote:
> 
> I'm currently struggling to write a web application for the company 
> where I work and I'm hoping you guys could make it easier for future 
> versions of me.
> 
> What I'm trying to do is have a large table of information where the row 
> and column headers are fixed but the contents scroll. It is possible in 
> JavaScript at the moment. For a good example (not written by me) see: 
> http://www.litotes.demon.co.uk/example_scripts/tableScroll.html

This is more of a rendering issue than a markup issue -- it's probably 
something the CSS working group should look at more closely. (We've looked 
at it before, but never for very long.)

Thanks for the feedback, though, I'll make sure to bring this up with the 
CSS WG again.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ajvincent at gmail.com  Wed Sep 20 01:05:55 2006
From: ajvincent at gmail.com (Alex Vincent)
Date: Wed, 20 Sep 2006 01:05:55 -0700
Subject: [whatwg] WF2: Clarification on valueMissing requested
Message-ID: <9301ed6b0609200105l555f6fbbu48da0dfd17a0c349@mail.gmail.com>

"The field has the required  attribute set but has no value selected."

In implementing this for Mozilla, I realized an edge case that could
prove troublesome.  Specifically, what happens if you have multiple
radio or checkboxes with the required attribute and no boxes checked
for any of them.

Alternatively, consider when the radio button is checked but doesn't
have a value... and some other radio input with the same name in the
same form does have a value.

There's an attempt to clarify it here:

"When a radio group has no checked radio button and more than one of
the radio buttons is marked as required, the UA should only tell the
user that the radio group as a whole is missing a value, not complain
about each radio button in turn, even though all of the radio buttons
marked with the required attribute would have the valueMissing flag
set."

Tell the user how?  Visually?  Through DOM events?  Both, or some
other way?  I'm working from the DOM events view right now, and this
could be the difference between dispatching one event and dispatching
many.

I don't require an immediate answer.  Forgive me if the questions
above have already been raised and discussed.

Alex Vincent

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001


From fora at annevankesteren.nl  Wed Sep 20 04:26:35 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Wed, 20 Sep 2006 11:26:35 -0000
Subject: [whatwg] MediaModeAbstractView and changing of media dynamically
In-Reply-To: <op.tf5ffmvzxl3at9@dragast.mshome.net>
References: <op.tf5ffmvzxl3at9@dragast.mshome.net>
Message-ID: <op.tf6cqlzvaw9dld@id-c0020.emi.ac.ma>

On Tue, 19 Sep 2006 23:27:12 -0000, Joao Eiras <joao.eiras at gmail.com>  
wrote:
> So, I suggest the creation of the 'media-change' event, which will fire  
> when the UA changes media, having the document as target.
> The event object could be an instance of a UIEvent, and have 2 extra  
> properties: newMediaMode, and oldMediaMode.

This has already been suggested multiple times on this list. Personally, I  
think a better place is probably the new CSSOM (whenever I get around to  
it...).


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From hallvors at gmail.com  Wed Sep 20 07:26:00 2006
From: hallvors at gmail.com (Hallvord R M Steen)
Date: Wed, 20 Sep 2006 16:26:00 +0200
Subject: [whatwg] scripts that remove focus from links during document
	navigation
Message-ID: <dd4c8a40609200726r6ecbc518i7ce91bbef0495016@mail.gmail.com>

( Previously sent to public-webapi at w3.org list but Anne v K agrees it
probably belongs here.. )

Opera has a serious usability problem for keyboard- and device-users when
pages do the following:

<a href="" onfocus="this.blur()">

This coding is very common because IE adds a small outline border to
focused links. Authors who do not like this will blur links when they are
activated to avoid this cosmetic issue. (Mea culpa: I've done exactly this
myself in sites I coded as a newbie, for that very reason.)

In Opera, when keyboard navigation hits this link, focus is removed. Thus
the link can not be activated from the keyboard and navigation may have to
start from the top of the document again.

We need some prose in a spec that allows a user agent to ignore blur() for
accessibility reasons. This text has been suggested by Fabian Valkenburg:

'scripts must not alter focus-related issues in a way that hinder keyboard
operation, and user agents may override any such use of focus-related
scripting operations.'

I'm not sure what spec to put it in, and we've also discussed possible
collateral damage if sites use this in legitimate ways. Thoughts?


-- 
Hallvord R. M. Steen


From lachlan.hunt at lachy.id.au  Wed Sep 20 09:17:30 2006
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Thu, 21 Sep 2006 02:17:30 +1000
Subject: [whatwg] scripts that remove focus from links during document
 navigation
In-Reply-To: <dd4c8a40609200726r6ecbc518i7ce91bbef0495016@mail.gmail.com>
References: <dd4c8a40609200726r6ecbc518i7ce91bbef0495016@mail.gmail.com>
Message-ID: <4511699A.7070306@lachy.id.au>

Hallvord R M Steen wrote:
> Opera has a serious usability problem for keyboard- and device-users when
> pages do the following:
> 
> <a href="" onfocus="this.blur()">
> 
> We need some prose in a spec that allows a user agent to ignore blur() for
> accessibility reasons...
> 
> I'm not sure what spec to put it in, and we've also discussed possible
> collateral damage if sites use this in legitimate ways. Thoughts?

What legitimate use cases are there for blur()?  I've never used it, 
I've never never seen it used in a way that hasn't forced me to disable 
script to workaround it, and my searches only found explanations of how 
to use it, not why or when to use it.

-- 
Lachlan Hunt
http://lachy.id.au/


From jim.ley at gmail.com  Wed Sep 20 14:07:25 2006
From: jim.ley at gmail.com (Jim Ley)
Date: Wed, 20 Sep 2006 22:07:25 +0100
Subject: [whatwg] scripts that remove focus from links during document
	navigation
In-Reply-To: <dd4c8a40609200726r6ecbc518i7ce91bbef0495016@mail.gmail.com>
References: <dd4c8a40609200726r6ecbc518i7ce91bbef0495016@mail.gmail.com>
Message-ID: <851c8d310609201407m7486b14cr9150095cbf050855@mail.gmail.com>

On 20/09/06, Hallvord R M Steen <hallvors at gmail.com> wrote:
> <a href="" onfocus="this.blur()">
>
> This coding is very common because IE adds a small outline border to
> focused links. Authors who do not like this will blur links when they are
> activated to avoid this cosmetic issue. (Mea culpa: I've done exactly this
> myself in sites I coded as a newbie, for that very reason.)

The reason being you'd not heard of the hidefocus attribute :-)  or
onfocus="this.hideFocus=true" if you want to be free.

> In Opera, when keyboard navigation hits this link, focus is removed. Thus
> the link can not be activated from the keyboard and navigation may have to
> start from the top of the document again.

Right so ignore it.

> We need some prose in a spec that allows a user agent to ignore blur() for
> accessibility reasons.

Why do you?  there's no prose in any spec which says you have to
support any script etc., and if there is, I would encourage you to
break it anyway, obviously anything that harms accessibility to your
users is something that it is your duty as a web-browser company to
not do.

I can appreciate you'd rather point to some other place and go "look,
look they said it was okay", but in that case you already have it UAAG
is fine for that.  I don't think it's good to spell out and make
specifications even longer just to give you somewhere to point pretty
deluded authors.

> 'scripts must not alter focus-related issues in a way that hinder keyboard
> operation, and user agents may override any such use of focus-related
> scripting operations.'

I don't like this, it doesn't define hinder well enough for a MUST,
can't you just take it as read that you're allowed to?

I can't foresee any realistic collateral damage from actually blocking
the behaviour - but if that genuinely is the case, then removing blur
entirely would be a more appropriate solution.

Mostly though I encourage you to continue in the vein of promoting
your user, rather than hiding behind spec's, you've done it so well to
date!

Jim.


From ian at hixie.ch  Thu Sep 21 12:29:41 2006
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 21 Sep 2006 19:29:41 +0000 (UTC)
Subject: [whatwg] Server-sent events or Server-sent DOM events?
In-Reply-To: <165276294.20060902104913@gmx.net>
References: <165276294.20060902104913@gmx.net>
Message-ID: <Pine.LNX.4.62.0609211928570.21538@dhalsim.dreamhost.com>

On Sat, 2 Sep 2006 akusaya at gmx.net wrote:
>
> Or is Server-sent DOM events a more specific name for Server-sent 
> events?

Server-sent DOM events is a more specific name.

I don't really like either name, if you have a better suggestion that 
would be fine too. You could also refer to the feature as "the 
event-source element" or something like that.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Sep 21 12:40:18 2006
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 21 Sep 2006 19:40:18 +0000 (UTC)
Subject: [whatwg] Editorial: parsing section
In-Reply-To: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>
References: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>
Message-ID: <Pine.LNX.4.62.0609211934140.21538@dhalsim.dreamhost.com>

On Sun, 10 Sep 2006, Anne van Kesteren wrote:
>
> When you have phrases like 'Change the insertion mode to "in select".' 
> it would be nice if "in select" was a pointer to the relevant section. 
> Currently "insertion mode" is a pointer and that's hardly useful.

The problem is the "in select" mode includes the start of the "in body" 
mode. e.g. whatever insertion mode you're in, if you find a <!DOCTYPE>, 
you have to handle it as described at the top of 8.2.4.3.7. But I suppose 
we could add the links anyway... What do you think? Do you really want the 
links, even though they'd be kind of technically incorrect?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From codedread at gmail.com  Fri Sep 22 14:04:27 2006
From: codedread at gmail.com (Jeff Schiller)
Date: Fri, 22 Sep 2006 16:04:27 -0500
Subject: [whatwg] Help with HTML5 Audio
Message-ID: <da131fde0609221404n1e1da1a9gc168015a1b3f16c0@mail.gmail.com>

Opera 9 implements the Audio interface proposed in HTML5:
http://whatwg.org/specs/web-apps/current-work/#scs-sound

I'm having trouble with it. My first attempt was:

var soundClip = new Audio("blah.wav");
if(soundClip) { soundClip.play(); }

This doesn't work on the first attempt, but on the second attempt it
plays the sound just fine. The only thing I could deduce was that the
first execution, the .play() lines was happening before the .wav file
finished loading from the server. But once the file is loaded from the
web server, subsequent invocations of this script mean the file has
cached, so the second line is happening after the load event.

Sure enough, the HTML5 spec talks about the "Audio object that will,
at the completion of the current script, start loading that URI" and
"Once the URI is loaded, a load event must be fired on the Audio
object"

So this was my second attempt:

function playSound(evt) {
if(evt && evt.target && evt.target.play) { evt.target.play(); }
}
...
var soundClip = new Audio("blah.wav");
if(soundClip) { soundClip.addEventListener("load", playSound, true); }

However, this doesn't seem to work at all (no matter how many times I
call it). So I'm not sure what I'm doing wrong. Is it possible that
I'm trying to add the event listener after the sound loads (in which
case the Load event already fires)? If so, how can I get around this?

I need a solution that will work whether the sound is cached or not.
Is this a problem in the spec or a problem with my understanding of
this object or event handlers?

Thanks,
Jeff


From codedread at gmail.com  Sat Sep 23 15:39:45 2006
From: codedread at gmail.com (Jeff Schiller)
Date: Sat, 23 Sep 2006 17:39:45 -0500
Subject: [whatwg] Help with HTML5 Audio
In-Reply-To: <da131fde0609221404n1e1da1a9gc168015a1b3f16c0@mail.gmail.com>
References: <da131fde0609221404n1e1da1a9gc168015a1b3f16c0@mail.gmail.com>
Message-ID: <da131fde0609231539n763fc622w1b00c0d0483d2d38@mail.gmail.com>

Thanks for all the replies off the mailing list...

This my just be an education problem.  Let me ask a few questions:

Do load events bubble up?  If so, can I add a load even listener to
the document and then catch the load events there always?

If so, how can I distinguish the target is of type Audio and not of
type HTMLImageElement (or whatever), just look for e.target.play?

If my understanding is not correct above (and I will test this later),
then it seems that the spec gives me no way to guarantee that I can
attach a load event listener to the Audio object prior to the song
loading (especially for cached sounds).

Although this doesn't help me for Opera 9, I would like to propose
that the Audio constructor's argument be OPTIONAL.  If there is no
argument, then the Audio object is created without any sound loaded
and all play(), loop(), etc would just return (or return an error or
throw an exception?).  Then, add a load() method to the interface
(which would produce a load event just as the construction with an
argument would).  This also allows me to reuse the Audio object
instead of creating an Audio object for each different sound...

Thanks,
Jeff


On 9/22/06, Jeff Schiller <codedread at gmail.com> wrote:
> Opera 9 implements the Audio interface proposed in HTML5:
> http://whatwg.org/specs/web-apps/current-work/#scs-sound
>
> I'm having trouble with it. My first attempt was:
>
> var soundClip = new Audio("blah.wav");
> if(soundClip) { soundClip.play(); }
>
> This doesn't work on the first attempt, but on the second attempt it
> plays the sound just fine. The only thing I could deduce was that the
> first execution, the .play() lines was happening before the .wav file
> finished loading from the server. But once the file is loaded from the
> web server, subsequent invocations of this script mean the file has
> cached, so the second line is happening after the load event.
>
> Sure enough, the HTML5 spec talks about the "Audio object that will,
> at the completion of the current script, start loading that URI" and
> "Once the URI is loaded, a load event must be fired on the Audio
> object"
>
> So this was my second attempt:
>
> function playSound(evt) {
> if(evt && evt.target && evt.target.play) { evt.target.play(); }
> }
> ...
> var soundClip = new Audio("blah.wav");
> if(soundClip) { soundClip.addEventListener("load", playSound, true); }
>
> However, this doesn't seem to work at all (no matter how many times I
> call it). So I'm not sure what I'm doing wrong. Is it possible that
> I'm trying to add the event listener after the sound loads (in which
> case the Load event already fires)? If so, how can I get around this?
>
> I need a solution that will work whether the sound is cached or not.
> Is this a problem in the spec or a problem with my understanding of
> this object or event handlers?
>
> Thanks,
> Jeff
>


From fora at annevankesteren.nl  Sun Sep 24 08:30:23 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Sun, 24 Sep 2006 17:30:23 +0200
Subject: [whatwg] Editorial: parsing section
In-Reply-To: <Pine.LNX.4.62.0609211934140.21538@dhalsim.dreamhost.com>
References: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.62.0609211934140.21538@dhalsim.dreamhost.com>
Message-ID: <op.tgdi9jqraw9dld@localhost>

On Thu, 21 Sep 2006 19:40:18 -0000, Ian Hickson <ian at hixie.ch> wrote:
>> When you have phrases like 'Change the insertion mode to "in select".'
>> it would be nice if "in select" was a pointer to the relevant section.
>> Currently "insertion mode" is a pointer and that's hardly useful.
>
> The problem is the "in select" mode includes the start of the "in body"
> mode. e.g. whatever insertion mode you're in, if you find a <!DOCTYPE>,
> you have to handle it as described at the top of 8.2.4.3.7. But I suppose
> we could add the links anyway... What do you think? Do you really want  
> the links, even though they'd be kind of technically incorrect?

The "in select" mode seems to assert something else than what you say,  
actually. It handles all cases itself already... Including "anything else".


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From ian at hixie.ch  Sun Sep 24 18:46:56 2006
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 25 Sep 2006 01:46:56 +0000 (UTC)
Subject: [whatwg] Editorial: parsing section
In-Reply-To: <op.tgdi9jqraw9dld@localhost>
References: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.62.0609211934140.21538@dhalsim.dreamhost.com>
	<op.tgdi9jqraw9dld@localhost>
Message-ID: <Pine.LNX.4.62.0609250145330.13053@dhalsim.dreamhost.com>

On Sun, 24 Sep 2006, Anne van Kesteren wrote:
>
> On Thu, 21 Sep 2006 19:40:18 -0000, Ian Hickson <ian at hixie.ch> wrote:
> > > When you have phrases like 'Change the insertion mode to "in 
> > > select".' it would be nice if "in select" was a pointer to the 
> > > relevant section. Currently "insertion mode" is a pointer and that's 
> > > hardly useful.
> > 
> > The problem is the "in select" mode includes the start of the "in 
> > body" mode. e.g. whatever insertion mode you're in, if you find a 
> > <!DOCTYPE>, you have to handle it as described at the top of 
> > 8.2.4.3.7. But I suppose we could add the links anyway... What do you 
> > think? Do you really want the links, even though they'd be kind of 
> > technically incorrect?
> 
> The "in select" mode seems to assert something else than what you say, 
> actually. It handles all cases itself already... Including "anything 
> else".

Your confusion here is exactly what I'm worried about. The point is that 
in the main phase, whatever the insertion mode, you have to start each 
token's processing from the start of the main phase. Which handles the 
DOCTYPEs and certain character nodes, before looking at the insertion mode 
flag and handling the other things (including "anything else").

Insertion modes are not phases. They are all processed as part of the main 
phase process each time.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From fora at annevankesteren.nl  Mon Sep 25 03:26:20 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Mon, 25 Sep 2006 12:26:20 +0200
Subject: [whatwg] Editorial: parsing section
In-Reply-To: <Pine.LNX.4.62.0609250145330.13053@dhalsim.dreamhost.com>
References: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.62.0609211934140.21538@dhalsim.dreamhost.com>
	<op.tgdi9jqraw9dld@localhost>
	<Pine.LNX.4.62.0609250145330.13053@dhalsim.dreamhost.com>
Message-ID: <op.tgfi961raw9dld@id-c0020.oslo.opera.com>

On Mon, 25 Sep 2006 03:46:56 +0200, Ian Hickson <ian at hixie.ch> wrote:
> Your confusion here is exactly what I'm worried about. The point is that
> in the main phase, whatever the insertion mode, you have to start each
> token's processing from the start of the main phase. Which handles the
> DOCTYPEs and certain character nodes, before looking at the insertion  
> mode flag and handling the other things (including "anything else").
>
> Insertion modes are not phases. They are all processed as part of the  
> main phase process each time.

Ah, I understand what you mean now (I think). Currently I only see DOCTYPE  
and "html" start tag there. Shouldn't Comment be there as well?

Anyway, perhaps you should have a note somewhere to make this more clear?


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From ian at hixie.ch  Mon Sep 25 10:01:34 2006
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 25 Sep 2006 17:01:34 +0000 (UTC)
Subject: [whatwg] Editorial: parsing section
In-Reply-To: <op.tgfi961raw9dld@id-c0020.oslo.opera.com>
References: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.62.0609211934140.21538@dhalsim.dreamhost.com>
	<op.tgdi9jqraw9dld@localhost>
	<Pine.LNX.4.62.0609250145330.13053@dhalsim.dreamhost.com>
	<op.tgfi961raw9dld@id-c0020.oslo.opera.com>
Message-ID: <Pine.LNX.4.62.0609251700340.13053@dhalsim.dreamhost.com>

On Mon, 25 Sep 2006, Anne van Kesteren wrote:
>
> On Mon, 25 Sep 2006 03:46:56 +0200, Ian Hickson <ian at hixie.ch> wrote:
> > Your confusion here is exactly what I'm worried about. The point is that
> > in the main phase, whatever the insertion mode, you have to start each
> > token's processing from the start of the main phase. Which handles the
> > DOCTYPEs and certain character nodes, before looking at the insertion mode
> > flag and handling the other things (including "anything else").
> > 
> > Insertion modes are not phases. They are all processed as part of the main
> > phase process each time.
> 
> Ah, I understand what you mean now (I think). Currently I only see DOCTYPE and
> "html" start tag there. Shouldn't Comment be there as well?

Comments are handled differently in "after body" mode than in the other 
modes.


> Anyway, perhaps you should have a note somewhere to make this more clear?

I'm not sure what the note would be and where it should go... can you 
suggest some text and a location? I'd love to make this clearer but I'm 
probably too close to it to understand how to do so.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From fora at annevankesteren.nl  Mon Sep 25 10:14:05 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Mon, 25 Sep 2006 19:14:05 +0200
Subject: [whatwg] Editorial: parsing section
In-Reply-To: <Pine.LNX.4.62.0609251700340.13053@dhalsim.dreamhost.com>
References: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.62.0609211934140.21538@dhalsim.dreamhost.com>
	<op.tgdi9jqraw9dld@localhost>
	<Pine.LNX.4.62.0609250145330.13053@dhalsim.dreamhost.com>
	<op.tgfi961raw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.62.0609251700340.13053@dhalsim.dreamhost.com>
Message-ID: <op.tgf15rmfaw9dld@id-c0020.oslo.opera.com>

On Mon, 25 Sep 2006 19:01:34 +0200, Ian Hickson <ian at hixie.ch> wrote:
>> Anyway, perhaps you should have a note somewhere to make this more  
>> clear?
>
> I'm not sure what the note would be and where it should go... can you
> suggest some text and a location? I'd love to make this clearer but I'm
> probably too close to it to understand how to do so.

After the first paragraph of section 8.2.4.3.6. you could have something  
like:

   Besides everything noted in the specific insertion mode
   covered by "Anything else" in "How to handle tokens in
   the main phase" the other items in that section are to
   considered as well when handling the specific insertion
   mode, such as a DOCTYPE token.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From ian at hixie.ch  Mon Sep 25 10:34:37 2006
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 25 Sep 2006 17:34:37 +0000 (UTC)
Subject: [whatwg] Editorial: parsing section
In-Reply-To: <op.tgf15rmfaw9dld@id-c0020.oslo.opera.com>
References: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.62.0609211934140.21538@dhalsim.dreamhost.com>
	<op.tgdi9jqraw9dld@localhost>
	<Pine.LNX.4.62.0609250145330.13053@dhalsim.dreamhost.com>
	<op.tgfi961raw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.62.0609251700340.13053@dhalsim.dreamhost.com>
	<op.tgf15rmfaw9dld@id-c0020.oslo.opera.com>
Message-ID: <Pine.LNX.4.62.0609251733200.13053@dhalsim.dreamhost.com>

On Mon, 25 Sep 2006, Anne van Kesteren wrote:
>
> On Mon, 25 Sep 2006 19:01:34 +0200, Ian Hickson <ian at hixie.ch> wrote:
> > > Anyway, perhaps you should have a note somewhere to make this more clear?
> > 
> > I'm not sure what the note would be and where it should go... can you
> > suggest some text and a location? I'd love to make this clearer but I'm
> > probably too close to it to understand how to do so.
> 
> After the first paragraph of section 8.2.4.3.6. you could have something like:
> 
>   Besides everything noted in the specific insertion mode
>   covered by "Anything else" in "How to handle tokens in
>   the main phase" the other items in that section are to
>   considered as well when handling the specific insertion
>   mode, such as a DOCTYPE token.

I'm not sure I understand what that means. :-)

It just struck me that maybe I should just fold all the insertion modes 
into phases and be done with it (and duplicate those two common rules 
across all the "insertion modes"). Maybe I'll do that. I've added an issue 
about doing that for now.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Mon Sep 25 21:23:25 2006
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 26 Sep 2006 04:23:25 +0000 (UTC)
Subject: [whatwg] WF2: Clarification on valueMissing requested
In-Reply-To: <9301ed6b0609200105l555f6fbbu48da0dfd17a0c349@mail.gmail.com>
References: <9301ed6b0609200105l555f6fbbu48da0dfd17a0c349@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0609260358520.4336@dhalsim.dreamhost.com>

On Wed, 20 Sep 2006, Alex Vincent wrote:
>
> "The field has the required  attribute set but has no value selected."
> 
> In implementing this for Mozilla, I realized an edge case that could
> prove troublesome.  Specifically, what happens if you have multiple
> radio or checkboxes with the required attribute and no boxes checked
> for any of them.
> 
> Alternatively, consider when the radio button is checked but doesn't
> have a value... and some other radio input with the same name in the
> same form does have a value.
> 
> There's an attempt to clarify it here:
> 
> "When a radio group has no checked radio button and more than one of
> the radio buttons is marked as required, the UA should only tell the
> user that the radio group as a whole is missing a value, not complain
> about each radio button in turn, even though all of the radio buttons
> marked with the required attribute would have the valueMissing flag
> set."
> 
> Tell the user how?  Visually?  Through DOM events?  Both, or some
> other way?  I'm working from the DOM events view right now, and this
> could be the difference between dispatching one event and dispatching
> many.

Clarified.

Let me know if that doesn't help.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ajvincent at gmail.com  Fri Sep 29 22:42:26 2006
From: ajvincent at gmail.com (Alex Vincent)
Date: Fri, 29 Sep 2006 22:42:26 -0700
Subject: [whatwg] WF2 clarification request: File upload controls
Message-ID: <9301ed6b0609292242h4bb22c6dg54c7c032572710a2@mail.gmail.com>

In the past, user agents have allowed file upload controls to
reference files not local to the computer in question.  For validity
purposes, I wonder if this should still be allowed under Web Forms
2.0.

Allowing remote values in the file upload control could be a
performance hit via networking, since we'd have to verify the file
exists before saying valueMissing is false...

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001


From canvasgame at gmail.com  Sat Sep 30 07:29:52 2006
From: canvasgame at gmail.com (Benjamin Joffe)
Date: Sun, 1 Oct 2006 00:29:52 +1000
Subject: [whatwg] Opera canvas bug?
Message-ID: <f9ec6ebb0609300729w2fb0d420qf03f3ad243808143@mail.gmail.com>

I have set up a few pages to demonstrate bugs with Opera's canvas
implementation. You can see it here:
http://abrahamjoffe.com.au/ben/opera_canvas_bugs/index.htm , I am sure that
the first 3 are genuine Opera bugs but the 4th one might not be because I do
not think that the WhatWG spec is specific enough with nested clipping
paths, none-the-less I feel that the way Firefox handles the script is more
correct than how Opera does. Would you agree?

Regards,
Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20061001/35a06f21/attachment.htm>

From whatwg at cycloid.f9.co.uk  Fri Sep  1 04:12:22 2006
From: whatwg at cycloid.f9.co.uk (Ric Hardacre)
Date: Fri, 01 Sep 2006 12:12:22 +0100
Subject: [whatwg] Scoped tabindex proposal
In-Reply-To: <004601c6cd5d$8fdd1080$3401a8c0@TERRA>
References: <BAY109-F6D3BB4EDC639EDA13E7C7B43F0@phx.gbl>
	<004601c6cd5d$8fdd1080$3401a8c0@TERRA>
Message-ID: <44F81596.50301@cycloid.f9.co.uk>



Andrew Fedoniouk wrote:
> 
> It is better to use another attribute for that, say - tabgroup.
> It should accept exactly the same set of values as tabindex.
> 
> <input tabindex="1" />
> <foo tabgroup="2">
>    <input tabindex="1" />
>    <input tabindex="2" />
> </foo>
> <input tabindex="3" />
> 
> The order of tab traversal of inputs will be in this case as
> their natural order (in this case).
> 
> tabgroup marked element may or may not have tabindex
> defined - so it can be focusable by itself.
> If both tabgroup and tabindex are defined and have numeric values then
> tabindex value is used as an index.
> 
> So it will be possible to say:
> <foo tabindex="2" tabgroup >
> 
> Andrew Fedoniouk.
> http://terrainformatica.com
> 
> 

how about allowing decimals, where by default "1" implies "1.0"? :

 <input tabindex="1" />
 <foo tabindex="2">
    <input tabindex="2.1" />
    <input tabindex="2.2" />
 </foo>
 <input tabindex="3" />

This also allows you to quickly associate the grouping of an input by
it's value when viewing the source:

<table>
<tr>
   <td><input tabindex="1.1" /></td>
   <td><input tabindex="2.1" /></td>
</tr>
<tr>
   <td><input tabindex="1.2" /></td>
   <td><input tabindex="2.2" /></td>
</tr>
<tr>
   <td></td>
   <td><button tabindex="3" /></td>
</tr>
</table>

obviously the above example could have just used tabindex 1 through 5
but you get the point

Ric Hardacre
http://www.cyclomedia.co.uk/




From zcorpan at hotmail.com  Fri Sep  1 04:57:30 2006
From: zcorpan at hotmail.com (Simon Pieters)
Date: Fri, 01 Sep 2006 11:57:30 +0000
Subject: [whatwg] Scoped tabindex proposal
In-Reply-To: <44F81596.50301@cycloid.f9.co.uk>
Message-ID: <BAY109-F348130203D37B2D2C1DA98B43C0@phx.gbl>

Hi,

From: Ric Hardacre <whatwg at cycloid.f9.co.uk>
>how about allowing decimals, where by default "1" implies "1.0"? :
>
>[...]
>
>This also allows you to quickly associate the grouping of an input by
>it's value when viewing the source:

You can already do that; just use tabindex 11, 21, 12, 22 and 30.

Regards,
Simon Pieters




From aaronlev at moonset.net  Fri Sep  1 07:00:37 2006
From: aaronlev at moonset.net (Aaron Leventhal)
Date: Fri, 01 Sep 2006 10:00:37 -0400
Subject: [whatwg] Scoped tabindex proposal
In-Reply-To: <BAY109-F6D3BB4EDC639EDA13E7C7B43F0@phx.gbl>
References: <BAY109-F6D3BB4EDC639EDA13E7C7B43F0@phx.gbl>
Message-ID: <44F83D05.0@moonset.net>

tabindex="-1" doesn't just remove items from the tab order. It also 
makes items focusable via mouse click or script, which is important when 
designing custom container widgets like spreadsheets, etc. via 
Javascript. In fact any negative value does it.

Don't try to overload the tabindex attribute. First, the browsers 
currently optimize it knowing that it's an integer. Second, the scoping 
is orthogonal. Third, magic values are less readable. It's voodoo.

- Aaron



Simon Pieters wrote:
> Hi,
>
> Currently if you want to use the tabindex to change the tab order you 
> mostly have to specify tabindex on all links and form controls prior 
> to the area you want to modify the tab order, because otherwise that 
> area would be before all prior elements in the tab order, which in 
> most cases isn't wanted. Therefore there's a need to scope tabindex 
> somehow.
>
> So here's an idea. A new value for the tabindex attribute, "scoped". 
> Here's an example:
>
>   <p>The following links should be focused in the order which the link 
> text indicates:
>   <p><a href="#">first</a>
>   <table tabindex="scoped">
>    <tr>
>     <td><a href="#" tabindex="1">second</a>
>     <td><a href="#" tabindex="3">forth</a>
>    <tr>
>     <td><a href="#" tabindex="2">third</a>
>     <td><a href="#" tabindex="4">fifth</a>
>   </table>
>   <p><a href="#">last</a>
>
> The table itself is not in the tab order and is not focusable.
>
> I'm not sure if we need another attribute or something for this 
> instead as .tabIndex is a long and not a DOMString. Or perhaps we 
> could say that all elements that have a tabindex attribute is a 
> scoping element, so that authors can use tabindex="-1" on the table 
> instead.
>
> Here's a pointer of where this (or something similar) is called for:
>
>   http://accessifyforum.com/viewtopic.php?t=6034
>
> Regards,
> Simon Pieters
>
>
>


From bfults at gmail.com  Fri Sep  1 10:43:09 2006
From: bfults at gmail.com (Brad Fults)
Date: Fri, 1 Sep 2006 10:43:09 -0700
Subject: [whatwg] Scoped tabindex proposal
In-Reply-To: <44F83D05.0@moonset.net>
References: <BAY109-F6D3BB4EDC639EDA13E7C7B43F0@phx.gbl>
	<44F83D05.0@moonset.net>
Message-ID: <1959130b0609011043x46eb2e7amf248490a053b3226@mail.gmail.com>

On 9/1/06, Aaron Leventhal <aaronlev at moonset.net> wrote:
> Don't try to overload the tabindex attribute. First, the browsers
> currently optimize it knowing that it's an integer. Second, the scoping
> is orthogonal. Third, magic values are less readable. It's voodoo.

Yes, yes, and yes. Completely agreed.

-- 
Brad Fults


From akusaya at gmx.net  Fri Sep  1 19:49:13 2006
From: akusaya at gmx.net (akusaya at gmx.net)
Date: Sat, 2 Sep 2006 10:49:13 +0800
Subject: [whatwg] Server-sent events or Server-sent DOM events?
Message-ID: <165276294.20060902104913@gmx.net>

Since Opera made a demo of the above technology, I want to publicize
it more. But I'm confused as what term is more suitable. There are two
mention of this technology in
http://whatwg.org/specs/web-apps/current-work/

In Abstract section,

"This specification introduces features to HTML and the DOM that ease
the authoring of Web-based applications. Additions include the context
menus, a direct-mode graphics canvas, inline popup windows, and
*server-sent events*."

But in Section 7.1,

7.1. [SCS] *Server-sent DOM events*

Which one is the correct term for that?

Or is Server-sent DOM events a more specific name for Server-sent
events?

Thank you.



From cbiesinger at web.de  Fri Sep  1 19:49:07 2006
From: cbiesinger at web.de (Christian Biesinger)
Date: Fri, 01 Sep 2006 19:49:07 -0700
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>
References: <44E68AA7.8080008@web.de>	
	<6b9c91b20608191008oc274b9dq39cc6f9aa025d8c1@mail.gmail.com>	
	<44E932EC.1020507@mit.edu>	
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>	
	<44EA1A02.4090207@mit.edu>
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>
Message-ID: <44F8F123.9010603@web.de>

Sorry for replying to this a bit late, but other stuff kept me 
distracted the last two weeks...

I should maybe also note that the purpose of the question wasn't so much 
to introduce new attributes to embed with (maybe) nicer semantics, but 
more about how to implement <embed> as it exists today in a web browser, 
Gecko in this case.

I should maybe also note that in Gecko, if you specify a type attribute 
the plugin will always be invoked, no matter what the content of the src 
attribute (indeed even if there is no src attribute), and also 
independent of what the server sends. (This is different from <object>, 
where on Gecko trunk the server-sent type always wins)

I also want to note that generally in HTML the type attributes are 
purely advisory and the server's type takes precedence, so I'm not 
really in favour of failing if the types don't match...

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 <object><embed></object> way really :)

> <object fallondata="true" codetype="type"  classid="clsid:123456"
> type="type" data="file.ext">
> <param name="src" value="file.ext">
> </object>
> 
> could be an answer to this.

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

> 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 <object> 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...

> 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?

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

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

<param> elements are only handled by the plugin itself...

-christian


From shadow2531 at gmail.com  Fri Sep  1 22:49:27 2006
From: shadow2531 at gmail.com (Shadow2531)
Date: Sat, 2 Sep 2006 01:49:27 -0400
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <44F8F123.9010603@web.de>
References: <44E68AA7.8080008@web.de>
	<6b9c91b20608191008oc274b9dq39cc6f9aa025d8c1@mail.gmail.com>
	<44E932EC.1020507@mit.edu>
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>
	<44EA1A02.4090207@mit.edu>
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>
	<44F8F123.9010603@web.de>
Message-ID: <6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>

On 9/1/06, Christian Biesinger <cbiesinger at web.de> 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 <object><embed></object> way really :)

:) Yeh, it's not THAT bad.

> > <object fallondata="true" codetype="type"  classid="clsid:123456"
> > type="type" data="file.ext">
> > <param name="src" value="file.ext">
> > </object>
> >
> > 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 <object> 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:

<object codebase="http://somesite.com/dir/">
    <param name="baseurl" "http://someothersite.com/">
</object>

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:

<param name="autostart" value="false">

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


From zcorpan at hotmail.com  Sat Sep  2 09:17:47 2006
From: zcorpan at hotmail.com (Simon Pieters)
Date: Sat, 02 Sep 2006 16:17:47 +0000
Subject: [whatwg] Scoped tabindex proposal
In-Reply-To: <44F83D05.0@moonset.net>
Message-ID: <BAY109-F156EDC848DE0D0E398C227B43D0@phx.gbl>

Hi,

From: Aaron Leventhal <aaronlev at moonset.net>
>tabindex="-1" doesn't just remove items from the tab order. It also makes 
>items focusable via mouse click or script, which is important when 
>designing custom container widgets like spreadsheets, etc. via Javascript. 
>In fact any negative value does it.

Indeed.

>Don't try to overload the tabindex attribute.

tabindex="scoped" is overloading indeed, but changing the tab order 
algorithm isn't really overloading the tabindex attribute (if we would say 
that all tabindex elements are scoping elements).

>First, the browsers currently optimize it knowing that it's an integer.

I agree that tabindex should still be a long (and not DOMString).

>Second, the scoping is orthogonal.

Then it would be better to have a separate attribute. That also allows the 
use of the current tab order for nested tabindex elements, and the ability 
to declare unfocusable scoping elements.

>Third, magic values are less readable. It's voodoo.

Ok.

Regards,
Simon Pieters




From anders.rundgren at telia.com  Sun Sep  3 00:31:37 2006
From: anders.rundgren at telia.com (Anders Rundgren)
Date: Sun, 3 Sep 2006 09:31:37 +0200
Subject: [whatwg] Modal Dialog Box support
Message-ID: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>

I know that this issue is a bit touchy among web purists but the fact is
that the world is going from surfing to applications.  The "wet dream" is
actually to get the same functionality in the browser like in a "fat client".

But it is very hard to create certain types of applications without having
modal dialogs.  AFAIK the existing alert() box is already modal (at least
in MSIE) so modality is well established.

That modal dialogs like featured in MSIE are not that much used
is because there is no similar function in other browsers.  You can
to some extent  "simulate" modality in Firefox but this simulation is
[of course...] not supported by MSIE.

The argument that tabbed browsing is incompatible with modality is
something I don't buy into, it is an implementation issue.  Exactly the
same issues should apply to alert() BTW.

Although AJAX may be great, it does in no way replace the need for
having modal "transaction points".

The net effect of ignoring legitimate needs of "legacy" app developers is
forcing them into using a single browser, possibly also using non-web
extensions like XAML.   I think this consideration is more important than
if a feature is absolutely "right" or "wrong". 

Sincerely
Anders Rundgren



From anders.rundgren at telia.com  Sun Sep  3 00:47:07 2006
From: anders.rundgren at telia.com (Anders Rundgren)
Date: Sun, 3 Sep 2006 09:47:07 +0200
Subject: [whatwg] Browser Signature Standards Proposal
Message-ID: <01cd01c6cf2d$28710010$82c5a8c0@arport2v>

F.Y.I.

I'm sorry about WASP, I was not aware of your activities when I created
the Web Activated Signature Protocol.

Background:
http://middleware.internet2.edu/pki06/proceedings/rundgren-websigning.ppt

Minimal technical description:
http://webpki.org/WASP-tutorial.pdf

The works:
http://webpki.org/WASP-specifications-2006-08-26.zip

There is [much] more if somebody is interested.

Anders Rundgren





From dveditz at cruzio.com  Mon Sep  4 09:27:39 2006
From: dveditz at cruzio.com (Daniel Veditz)
Date: Mon, 04 Sep 2006 09:27:39 -0700
Subject: [whatwg] Persistent storage is critically flawed.
In-Reply-To: <Pine.LNX.4.62.0608282350000.10139@dhalsim.dreamhost.com>
References: <44F18BE5.2040103@arc.net.au>	<403d38e20608272109v278a0e76q52cba55a60ffce42@mail.gmail.com>	<44F28679.6030200@arc.net.au>	<851c8d310608280127x9d18878n4a4b1ca4e36eabd9@mail.gmail.com>	<6c97b8b10608280431w55960cf3s887703c57dc5024b@mail.gmail.com>
	<Pine.LNX.4.62.0608282350000.10139@dhalsim.dreamhost.com>
Message-ID: <44FC53FB.1040301@cruzio.com>

Ian Hickson wrote:
> Note that the problems you raise also exist (and have long existed) with 
> cookies; at least the storage APIs default to a safe state in the general 
> case instead of defaulting to an unsafe state.

In what way do the storage API's default to a "safe state"? What "unsafe
state" is the alternative? You've lost me.

Compared to cookies storage seems less safe: the default cookie access
is to the setting host only, a case that does not even exist with global
storage. To publish a cookie to a wider family of hosts the setting host
must explicitly set a domain on the cookie. (Ditto path, but that turns
out to be illusory protection due to the DOM same-origin policy).

Web-app developers aren't complaining they can't read cookies they need
from sub-domains, they're complaining when private cookies leak or when
they're fooled by a cookie injected at a higher domain (e.g. .co.uk
cookies).

Let me throw out two alternatives for providing "private" persistent
storage, neither of which complicates the API (though may complicate the
implementation).

The first piggy-backs on the domain vs host cookie concept as applied to
entire storage objects. Each host would have a private persistent
storage object that could only be accessed by that host; shared objects
would need to be explicitly named. There should be a difference in how
the two types are named
  a) using the cookie domain nomenclature to indicate the similar
  concepts "www.foo.com" could represent the host storage only
  accessible to that host, and a leading '.' in ".www.foo.com"
  would represent a shared storage area. You could argue that
  people will forget the dot as they do with cookie domains,
  but they only do with cookies because UA's let them get away
  with it.
  b) another choice would be to make globalStorage[''] magic and
  mean the private storage for the current host. No one is going
  to implement universally accessible storage (the spec even
  recommends against it), you could just take that out of the spec
  and reuse it for this. All other named areas would be shared
  as described by the spec.

The second alternative would be to have private and shared storage items
within a single storage area. I know you weren't keen on adding another
attribute like "secure", what if instead there was a convention such as
"keys which start with an underscore are private and can only be
accessed if the current host matches the storage area domain".

My personal preference is for 1b -- use globalStorage[''] as the
non-shared storage area.

-Dan Veditz




From webmaster at keryx.se  Mon Sep  4 10:37:30 2006
From: webmaster at keryx.se (Keryx webb)
Date: Mon, 04 Sep 2006 19:37:30 +0200
Subject: [whatwg] href on any element
In-Reply-To: <op.te14t6uc4suneb@g5.local>
References: <002401c6cb84$83a07350$0500a8c0@computername>
	<op.te14t6uc4suneb@g5.local>
Message-ID: <44FC645A.405@keryx.se>

Sorry for starting a thread and then being away for quite a while. I've been 
exceptionally busy!

Let's clarify some of my wishes:

Do I wish that the href-attribute is available on exactly *every* element? No, 
but on many *more* than today.

A. I do find myself writing a lot of:
<abbr title="foobar"><a href="foo">bar</a></abbr>
<dfn><a href="foo">bar</a></dfn>
<em><a href="foo">bar</a></em>


B. I also find myself writing large amounts of:
<ul>
<li><a href="page1">Menuitem 1</a></li>
<li><a href="page2">Menuitem 2</a></li>
</ul>

To make the whole LI-element clickable I have to resort to CSS
( ul#nav li a { display: block } ) which does not work in all browsers or 
JavaScript, which also is a hassle.

Why would it be better to loose the a-tags?
- Code-reduction is always a good thing! (The XLink solution means a lot of
   code => no reduction.)
- Convenience for hand-coders, whose work often make it into CMS-templates.

Will it break backwards compatibility? Yes, if todays browsers are supposed to 
be able to render WHATWG-pages. But there are lots of other things in WHATWG 
that they do not understand either. It's only the very latest browsers that can 
handle canvas. No browser fully implements Web Forms 2.0 (as far as I know).

Please point me to a document if I've got this wrong - I am after all a newbie 
on this list - but adding href on more elements is not *changing* todays HTML, 
but *adding* to it. Isn't that what HTML 5 is all about.

And how much it may be disliked by browser vendors, I still think they do intend 
to support XHTML 2.0, and need to prepare for a day when href is available on 
*most* elements, anyway.

Actually, if one dislikes XHTML 2.0, implementing its one "killer feature" in 
HTML 5 would make sense as well. Who would want to use XHTML 2.0 if it does not 
offer any significant advantage?

As Molly H writes:
"All I really, really want from XHTML 2.0 is href to be available for any 
element." (I'd like to change that to "many more elements than today") 
http://www.molly.com/2006/08/14/angry-not-zeldman-meyer-and-fair-concerns-about-the-w3c/



Lars Gunther



From cbiesinger at web.de  Mon Sep  4 15:49:56 2006
From: cbiesinger at web.de (Christian Biesinger)
Date: Mon, 04 Sep 2006 15:49:56 -0700
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>
References: <44E68AA7.8080008@web.de>	
	<6b9c91b20608191008oc274b9dq39cc6f9aa025d8c1@mail.gmail.com>	
	<44E932EC.1020507@mit.edu>	
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>	
	<44EA1A02.4090207@mit.edu>	
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>	
	<44F8F123.9010603@web.de>
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>
Message-ID: <44FCAD94.2050704@web.de>

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".

> 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 <object>), but that's all. It 
certainly doesn't map codebase to anything else.

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

Yes, that would be good. Although perhaps WhatWG is the wrong spec for 
this, since it won't describe a plugin API...

> As for the priority deal. Here's an example:
> 
> <object codebase="http://somesite.com/dir/">
>    <param name="baseurl" "http://someothersite.com/">
> </object>

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).

> 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.

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...

-christian



From christoph.paeper at crissov.de  Tue Sep  5 01:39:33 2006
From: christoph.paeper at crissov.de (=?ISO-8859-1?Q?Christoph_P=E4per?=)
Date: Tue, 5 Sep 2006 10:39:33 +0200
Subject: [whatwg] return lowercase hex values for fillStyle and
	strokeStyle
In-Reply-To: <op.te2afeqjaw9dld@id-c0020.oslo.opera.com>
References: <op.te2afeqjaw9dld@id-c0020.oslo.opera.com>
Message-ID: <2AADA27A-0DFA-46EC-B384-7754DF5FBDBB@crissov.de>

*Anne van Kesteren*:
> Instead of returning an uppercase six digit hex value I suggest  
> returning a lowercase value for compatibility with what UAs  
> (including IE) currently do

It may be the right decision on compatibility grounds, but other than  
that lowercase hexadecimal digits (0-9, a-f) are almost always a bad  
choice, because a, c and e have no ascenders like every hindu-arabic  
decimal digit has and thus make the number harder to read. This  
obviously does not apply to fonts with old-style numerals aka. text  
figures, where 0, 1 and 2 have neither ascenders (like 6 and 8) nor  
descenders (like 3, 4, 5, 7 and 9), but those are rather unlikely to  
be used in a programming environment.


From christoph.paeper at crissov.de  Tue Sep  5 02:01:38 2006
From: christoph.paeper at crissov.de (=?ISO-8859-1?Q?Christoph_P=E4per?=)
Date: Tue, 5 Sep 2006 11:01:38 +0200
Subject: [whatwg] Modal Dialog Box support
In-Reply-To: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>
Message-ID: <BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>

*Anders Rundgren*:
> But it is very hard to create certain types of applications without  
> having
> modal dialogs.

That does not mean modal dialogs were a good idea, ever.



From anders.rundgren at telia.com  Tue Sep  5 02:30:23 2006
From: anders.rundgren at telia.com (Anders Rundgren)
Date: Tue, 5 Sep 2006 11:30:23 +0200
Subject: [whatwg] Modal Dialog Box support
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>
	<BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>
Message-ID: <005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>

>> But it is very hard to create certain types of applications without  
>> having  modal dialogs.

>That does not mean modal dialogs were a good idea, ever.

Christoph,

You are free to not use modal dialog in *your* applications.

You are also free to support end-users when windows magically "disappear"
because the [stupid] user in some way activated the wrong window.

You are also free to write the booklet "Dialogs for dummies", where you describe
for the world of legacy software developers why the concept of a transaction point
which is a core facility in a database system, should not have a GUI counterpart.

However, I would be less pleased if such ideas become the basis for standards
development because that without doubt leads to fragmentation, since not all
vendors can afford a "von oben/besserwisser" attitude towards their customers.

I once started out myself with the idea of bringing "perfect" solutions to the market.
Unfortunately, what was probably perfect for some people turned out as useless
for another group :-(

thanx,
Anders R



From rimantas at gmail.com  Tue Sep  5 02:46:35 2006
From: rimantas at gmail.com (Rimantas Liubertas)
Date: Tue, 5 Sep 2006 12:46:35 +0300
Subject: [whatwg] Modal Dialog Box support
In-Reply-To: <005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>
	<BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>
	<005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>
Message-ID: <5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com>

<...>
> You are also free to write the booklet "Dialogs for dummies", where you describe
> for the world of legacy software developers why the concept of a transaction point
> which is a core facility in a database system, should not have a GUI counterpart.
<...>

Chapter 30 "Using Dialogs" in "About the Face 2.0" [1] by Alan Cooper
makes a good
read too.

[1] http://www.amazon.com/About-Face-2-0-Essentials-Interaction/dp/0764526413/sr=8-1/qid=1157449548/ref=pd_bbs_1/102-1456987-0371351?ie=UTF8&s=books

Regards,
Rimantas
--
http://rimantas.com/


From chaals at opera.com  Tue Sep  5 04:54:10 2006
From: chaals at opera.com (Charles McCathieNevile)
Date: Tue, 05 Sep 2006 13:54:10 +0200
Subject: [whatwg] return lowercase hex values for fillStyle and
	strokeStyle
In-Reply-To: <2AADA27A-0DFA-46EC-B384-7754DF5FBDBB@crissov.de>
References: <op.te2afeqjaw9dld@id-c0020.oslo.opera.com>
	<2AADA27A-0DFA-46EC-B384-7754DF5FBDBB@crissov.de>
Message-ID: <op.tfel0kciwxe0ny@widsith.local>

On Tue, 05 Sep 2006 10:39:33 +0200, Christoph P?per  
<christoph.paeper at crissov.de> wrote:

> *Anne van Kesteren*:
>> Instead of returning an uppercase six digit hex value I suggest  
>> returning a lowercase value for compatibility with what UAs (including  
>> IE) currently do
>
> It may be the right decision on compatibility grounds, but other than  
> that lowercase hexadecimal digits (0-9, a-f) are almost always a bad  
> choice, because a, c and e have no ascenders like every hindu-arabic  
> decimal digit has and thus make the number harder to read. This  
> obviously does not apply to fonts with old-style numerals aka. text  
> figures, where 0, 1 and 2 have neither ascenders (like 6 and 8) nor  
> descenders (like 3, 4, 5, 7 and 9), but those are rather unlikely to be  
> used in a programming environment.

I believe this, but I suspect that the gain in compatibility is well worth  
the minor loss in efficiency for people who are hand-coding.

Cheers

Chaals

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo espa?ol  -  je parle fran?ais  -  jeg l?rer norsk
chaals at opera.com          Try Opera 9 now! http://opera.com


From shadow2531 at gmail.com  Tue Sep  5 07:20:06 2006
From: shadow2531 at gmail.com (Shadow2531)
Date: Tue, 5 Sep 2006 10:20:06 -0400
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <44FCAD94.2050704@web.de>
References: <44E68AA7.8080008@web.de>
	<6b9c91b20608191008oc274b9dq39cc6f9aa025d8c1@mail.gmail.com>
	<44E932EC.1020507@mit.edu>
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>
	<44EA1A02.4090207@mit.edu>
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>
	<44F8F123.9010603@web.de>
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>
	<44FCAD94.2050704@web.de>
Message-ID: <6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>

On 9/4/06, Christian Biesinger <cbiesinger at web.de> 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 <object>), but that's all. It
> certainly doesn't map codebase to anything else.
> > As for the priority deal. Here's an example:
> >
> > <object codebase="http://somesite.com/dir/">
> >    <param name="baseurl" "http://someothersite.com/">
> > </object>
>
> 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, <param name="autostart" value="false" doesn't work for
WMP unless you're using activex. It has to be value="0" for it to work
for the netscape version.

I'd love to see it work with 'true", but ....

I think Gecko did map true -> 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


From bzbarsky at mit.edu  Tue Sep  5 08:35:34 2006
From: bzbarsky at mit.edu (Boris Zbarsky)
Date: Tue, 05 Sep 2006 10:35:34 -0500
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>
References: <44E68AA7.8080008@web.de>	
	<6b9c91b20608191008oc274b9dq39cc6f9aa025d8c1@mail.gmail.com>	
	<44E932EC.1020507@mit.edu>	
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>	
	<44EA1A02.4090207@mit.edu>	
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>	
	<44F8F123.9010603@web.de>	
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>	
	<44FCAD94.2050704@web.de>
	<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>
Message-ID: <44FD9946.2000905@mit.edu>

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.

-Boris


From contact at nickshanks.com  Tue Sep  5 10:07:35 2006
From: contact at nickshanks.com (Nicholas Shanks)
Date: Tue, 5 Sep 2006 18:07:35 +0100
Subject: [whatwg] return lowercase hex values for fillStyle and
	strokeStyle
In-Reply-To: <op.tfel0kciwxe0ny@widsith.local>
References: <op.te2afeqjaw9dld@id-c0020.oslo.opera.com>
	<2AADA27A-0DFA-46EC-B384-7754DF5FBDBB@crissov.de>
	<op.tfel0kciwxe0ny@widsith.local>
Message-ID: <3A69E3AC-30A9-4DAB-8896-CD593EF1B115@nickshanks.com>

On 5 Sep 2006, at 12:54, Charles McCathieNevile wrote:

>>> Instead of returning an uppercase six digit hex value I suggest  
>>> returning a lowercase value for compatibility with what UAs  
>>> (including IE) currently do
>>
>> It may be the right decision on compatibility grounds, but other  
>> than that lowercase hexadecimal digits (0-9, a-f) are almost  
>> always a bad choice, because a, c and e have no ascenders like  
>> every hindu-arabic decimal digit has and thus make the number  
>> harder to read. This obviously does not apply to fonts with old- 
>> style numerals aka. text figures, where 0, 1 and 2 have neither  
>> ascenders (like 6 and 8) nor descenders (like 3, 4, 5, 7 and 9),  
>> but those are rather unlikely to be used in a programming  
>> environment.
>
> I believe this, but I suspect that the gain in compatibility is  
> well worth the minor loss in efficiency for people who are hand- 
> coding.

I disagree, and always prefer uppercase hex digits to lowercase ones,  
it makes the numbers easier to read IMO.

- Nicholas.


From cbiesinger at web.de  Tue Sep  5 10:32:44 2006
From: cbiesinger at web.de (Christian Biesinger)
Date: Tue, 05 Sep 2006 10:32:44 -0700
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>
References: <44E68AA7.8080008@web.de>	
	<6b9c91b20608191008oc274b9dq39cc6f9aa025d8c1@mail.gmail.com>	
	<44E932EC.1020507@mit.edu>	
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>	
	<44EA1A02.4090207@mit.edu>	
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>	
	<44F8F123.9010603@web.de>	
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>	
	<44FCAD94.2050704@web.de>
	<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>
Message-ID: <44FDB4BC.3080105@web.de>

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?

> 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.

> 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?

> 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?




From chaals at opera.com  Tue Sep  5 10:48:33 2006
From: chaals at opera.com (Charles McCathieNevile)
Date: Tue, 05 Sep 2006 19:48:33 +0200
Subject: [whatwg] return lowercase hex values for fillStyle and
	strokeStyle
In-Reply-To: <3A69E3AC-30A9-4DAB-8896-CD593EF1B115@nickshanks.com>
References: <op.te2afeqjaw9dld@id-c0020.oslo.opera.com>
	<2AADA27A-0DFA-46EC-B384-7754DF5FBDBB@crissov.de>
	<op.tfel0kciwxe0ny@widsith.local>
	<3A69E3AC-30A9-4DAB-8896-CD593EF1B115@nickshanks.com>
Message-ID: <op.tfe2e7o7wxe0ny@widsith.local>

On Tue, 05 Sep 2006 19:07:35 +0200, Nicholas Shanks  
<contact at nickshanks.com> wrote:

> On 5 Sep 2006, at 12:54, Charles McCathieNevile wrote:
>
>>>> Instead of returning an uppercase six digit hex value I suggest  
>>>> returning a lowercase value for compatibility with what UAs  
>>>> (including IE) currently do
>>>
>>> It may be the right decision on compatibility grounds, but other than  
>>> that lowercase hexadecimal digits (0-9, a-f) are almost always a bad  
>>> choice, because a, c and e have no ascenders like every hindu-arabic  
>>> decimal digit has and thus make the number harder to read. This  
>>> obviously does not apply to fonts with old-style numerals aka. text  
>>> figures, where 0, 1 and 2 have neither ascenders (like 6 and 8) nor  
>>> descenders (like 3, 4, 5, 7 and 9), but those are rather unlikely to  
>>> be used in a programming environment.
>>
>> I believe this, but I suspect that the gain in compatibility is well  
>> worth the minor loss in efficiency for people who are hand-coding.
>
> I disagree, and always prefer uppercase hex digits to lowercase ones, it  
> makes the numbers easier to read IMO.

That is, I think, what Christopher said and I agreed with. I still think  
that compatibility with deployed browsers should, in this case, trump that  
usability gain.

cheers

Chaals

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo espa?ol  -  je parle fran?ais  -  jeg l?rer norsk
chaals at opera.com          Try Opera 9 now! http://opera.com


From shadow2531 at gmail.com  Tue Sep  5 10:56:46 2006
From: shadow2531 at gmail.com (Shadow2531)
Date: Tue, 5 Sep 2006 13:56:46 -0400
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <44FD9946.2000905@mit.edu>
References: <44E68AA7.8080008@web.de> <44E932EC.1020507@mit.edu>
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>
	<44EA1A02.4090207@mit.edu>
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>
	<44F8F123.9010603@web.de>
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>
	<44FCAD94.2050704@web.de>
	<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>
	<44FD9946.2000905@mit.edu>
Message-ID: <6b9c91b20609051056u59ae17a0ua9dfd2394d1835cf@mail.gmail.com>

On 9/5/06, Boris Zbarsky <bzbarsky at mit.edu> 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


From bzbarsky at mit.edu  Tue Sep  5 11:08:56 2006
From: bzbarsky at mit.edu (Boris Zbarsky)
Date: Tue, 05 Sep 2006 13:08:56 -0500
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <6b9c91b20609051056u59ae17a0ua9dfd2394d1835cf@mail.gmail.com>
References: <44E68AA7.8080008@web.de> <44E932EC.1020507@mit.edu>	
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>	
	<44EA1A02.4090207@mit.edu>	
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>	
	<44F8F123.9010603@web.de>	
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>	
	<44FCAD94.2050704@web.de>	
	<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>	
	<44FD9946.2000905@mit.edu>
	<6b9c91b20609051056u59ae17a0ua9dfd2394d1835cf@mail.gmail.com>
Message-ID: <44FDBD38.3020306@mit.edu>

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

It does.

> 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.

> 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?

-Boris


From fora at annevankesteren.nl  Tue Sep  5 11:51:33 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Tue, 05 Sep 2006 20:51:33 +0200
Subject: [whatwg] href on any element
In-Reply-To: <44FC645A.405@keryx.se>
References: <002401c6cb84$83a07350$0500a8c0@computername>
	<op.te14t6uc4suneb@g5.local> <44FC645A.405@keryx.se>
Message-ID: <op.tfe5b7xsaw9dld@id-c0020.oslo.opera.com>

On Mon, 04 Sep 2006 19:37:30 +0200, Keryx webb <webmaster at keryx.se> wrote:
> To make the whole LI-element clickable I have to resort to CSS
> ( ul#nav li a { display: block } ) which does not work in all browsers  
> or JavaScript, which also is a hassle.

Yeah, <li href="">test</li> does work in all browsers obviously. Seems  
like a good reason to put it in HTML5!


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From shadow2531 at gmail.com  Tue Sep  5 12:08:56 2006
From: shadow2531 at gmail.com (Shadow2531)
Date: Tue, 5 Sep 2006 15:08:56 -0400
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <44FDBD38.3020306@mit.edu>
References: <44E68AA7.8080008@web.de> <44EA1A02.4090207@mit.edu>
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>
	<44F8F123.9010603@web.de>
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>
	<44FCAD94.2050704@web.de>
	<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>
	<44FD9946.2000905@mit.edu>
	<6b9c91b20609051056u59ae17a0ua9dfd2394d1835cf@mail.gmail.com>
	<44FDBD38.3020306@mit.edu>
Message-ID: <6b9c91b20609051208g1617d9f9n12b26feff746437b@mail.gmail.com>

On 9/5/06, Boris Zbarsky <bzbarsky at mit.edu> 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


From jg307 at cam.ac.uk  Tue Sep  5 12:38:33 2006
From: jg307 at cam.ac.uk (James Graham)
Date: Tue, 05 Sep 2006 20:38:33 +0100
Subject: [whatwg] href on any element
In-Reply-To: <44FC645A.405@keryx.se>
References: <002401c6cb84$83a07350$0500a8c0@computername>	<op.te14t6uc4suneb@g5.local>
	<44FC645A.405@keryx.se>
Message-ID: <44FDD239.7030308@cam.ac.uk>

Keryx webb wrote:

> Will it break backwards compatibility? Yes, if todays browsers are 
> supposed to be able to render WHATWG-pages. But there are lots of other 
> things in WHATWG that they do not understand either. It's only the very 
> latest browsers that can handle canvas. No browser fully implements Web 
> Forms 2.0 (as far as I know).

But there is usually some way to use other HTML5/WF2 features without 
breaking current browsers. The only way I can see to do this with href 
on many elements is to manually walk the DOM inserting <a href="bar" /> 
elements as children of the <foo href="bar" /> elements, with some care 
needed for elements such as <tr> that really won't take <a> as a child. 
Authors doing this would also have to be very careful about not breaking 
their CSS rules etc. in current browsers.

href on multiple elements is a nice idea but I'm not sure the benefits 
outweigh the costs.


From shadow2531 at gmail.com  Tue Sep  5 12:48:55 2006
From: shadow2531 at gmail.com (Shadow2531)
Date: Tue, 5 Sep 2006 15:48:55 -0400
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <44FDB4BC.3080105@web.de>
References: <44E68AA7.8080008@web.de> <44E932EC.1020507@mit.edu>
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>
	<44EA1A02.4090207@mit.edu>
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>
	<44F8F123.9010603@web.de>
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>
	<44FCAD94.2050704@web.de>
	<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>
	<44FDB4BC.3080105@web.de>
Message-ID: <6b9c91b20609051248g1b04602ewcb22effdf99fa628@mail.gmail.com>

On 9/5/06, Christian Biesinger <cbiesinger at web.de> 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 :

<object type="application/x-shockwave-flash"
codebase="http://www.adobe.com/"
data="shockwave/download/triggerpages_mmcom/flash.swf" width="300"
height="120"></object>

> > 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


From mattraymond at earthlink.net  Tue Sep  5 16:27:28 2006
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Tue, 05 Sep 2006 19:27:28 -0400
Subject: [whatwg] Modal Dialog Box support
In-Reply-To: <5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>	<BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>	<005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>
	<5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com>
Message-ID: <44FE07E0.9080308@earthlink.net>

Rimantas Liubertas wrote:
[Snip!]
> Chapter 30 "Using Dialogs" in "About the Face 2.0" [1] by Alan Cooper
> makes a good
> read too.
> 
> [1] http://www.amazon.com/About-Face-2-0-Essentials-Interaction/dp/0764526413/sr=8-1/qid=1157449548/ref=pd_bbs_1/102-1456987-0371351?ie=UTF8&s=books


   So, what, we're supposed to order and read a book from Amazon.com in
order to know what you're talking about?


From cbiesinger at web.de  Tue Sep  5 19:45:04 2006
From: cbiesinger at web.de (Christian Biesinger)
Date: Tue, 05 Sep 2006 19:45:04 -0700
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <6b9c91b20609051248g1b04602ewcb22effdf99fa628@mail.gmail.com>
References: <44E68AA7.8080008@web.de> <44E932EC.1020507@mit.edu>	
	<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>	
	<44EA1A02.4090207@mit.edu>	
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>	
	<44F8F123.9010603@web.de>	
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>	
	<44FCAD94.2050704@web.de>	
	<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>	
	<44FDB4BC.3080105@web.de>
	<6b9c91b20609051248g1b04602ewcb22effdf99fa628@mail.gmail.com>
Message-ID: <44FE3630.7090002@web.de>

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

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

> 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.

> 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.

It does help something. It helps all browser makers by not finding out 
what specific hacks certain plugins want when the right place to fix it 
is in the plugin itself.

> 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 :)

Anyway... we seem to have some disagreement... and this is perhaps not 
even in the scope of a spec that describes HTML... so guess we'll leave 
it at that :)

-christian


From cbiesinger at web.de  Tue Sep  5 19:48:33 2006
From: cbiesinger at web.de (Christian Biesinger)
Date: Tue, 05 Sep 2006 19:48:33 -0700
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <44FDBD38.3020306@mit.edu>
References: <44E68AA7.8080008@web.de>
	<44E932EC.1020507@mit.edu>		<6b9c91b20608211225p298fe255x67aa80c2f120afb8@mail.gmail.com>		<44EA1A02.4090207@mit.edu>		<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>		<44F8F123.9010603@web.de>		<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>		<44FCAD94.2050704@web.de>		<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>		<44FD9946.2000905@mit.edu>	<6b9c91b20609051056u59ae17a0ua9dfd2394d1835cf@mail.gmail.com>
	<44FDBD38.3020306@mit.edu>
Message-ID: <44FE3701.6080309@web.de>

Boris Zbarsky wrote:
>> 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.

Well that depends on the plugin, the other way (the one I consider 
normal ;) ) gives the plugin the actual chunks of data sequentially. 
Guess that amounts to almost the same.


From shadow2531 at gmail.com  Wed Sep  6 05:10:22 2006
From: shadow2531 at gmail.com (Shadow2531)
Date: Wed, 6 Sep 2006 08:10:22 -0400
Subject: [whatwg] WhatWG and <embed>
In-Reply-To: <44FE3630.7090002@web.de>
References: <44E68AA7.8080008@web.de> <44EA1A02.4090207@mit.edu>
	<6b9c91b20608211548j29f9b119t6f0d14bbb8b8308f@mail.gmail.com>
	<44F8F123.9010603@web.de>
	<6b9c91b20609012249v1e3f0d77j69ce2db498561a01@mail.gmail.com>
	<44FCAD94.2050704@web.de>
	<6b9c91b20609050720p5f6d470bu6ba97647a061bcda@mail.gmail.com>
	<44FDB4BC.3080105@web.de>
	<6b9c91b20609051248g1b04602ewcb22effdf99fa628@mail.gmail.com>
	<44FE3630.7090002@web.de>
Message-ID: <6b9c91b20609060510l56dc8aa1j200a9cf3ac7ea00e@mail.gmail.com>

On 9/5/06, Christian Biesinger <cbiesinger at web.de> wrote:
> Shadow2531 wrote:
> > The FF ( trunk or 1.5.0.6) codebase problem doesn't happen with Flash
> > as you can see from :
> >
> > <object type="application/x-shockwave-flash"
> > codebase="http://www.adobe.com/"
> > data="shockwave/download/triggerpages_mmcom/flash.swf" width="300"
> > height="120"></object>
>
> 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


From chaals at opera.com  Wed Sep  6 07:44:54 2006
From: chaals at opera.com (Charles McCathieNevile)
Date: Wed, 06 Sep 2006 16:44:54 +0200
Subject: [whatwg] Modal Dialog Box support
In-Reply-To: <44FE07E0.9080308@earthlink.net>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>
	<BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>
	<005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>
	<5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com>
	<44FE07E0.9080308@earthlink.net>
Message-ID: <op.tfgok4kfwxe0ny@widsith.local>

On Wed, 06 Sep 2006 01:27:28 +0200, Matthew Raymond  
<mattraymond at earthlink.net> wrote:

> Rimantas Liubertas wrote:
> [Snip!]
>> Chapter 30 "Using Dialogs" in "About the Face 2.0" [1] by Alan Cooper
>> makes a good read too.
>>
>> [1]  
>> http://www.amazon.com/About-Face-2-0-Essentials-Interaction/dp/0764526413/sr=8-1/qid=1157449548/ref=pd_bbs_1/102-1456987-0371351?ie=UTF8&s=books
>
>
>    So, what, we're supposed to order and read a book from Amazon.com in
> order to know what you're talking about?

You could always go to a library. I believe the reference was offered as  
something useful, should you be inclined to take the time.

Cheers

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo espa?ol  -  je parle fran?ais  -  jeg l?rer norsk
chaals at opera.com          Try Opera 9 now! http://opera.com


From jg307 at cam.ac.uk  Wed Sep  6 08:46:02 2006
From: jg307 at cam.ac.uk (James Graham)
Date: Wed, 06 Sep 2006 16:46:02 +0100
Subject: [whatwg] Modal Dialog Box support
In-Reply-To: <op.tfgok4kfwxe0ny@widsith.local>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>	<BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>	<005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>	<5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com>	<44FE07E0.9080308@earthlink.net>
	<op.tfgok4kfwxe0ny@widsith.local>
Message-ID: <44FEED3A.1000004@cam.ac.uk>

Charles McCathieNevile wrote:
> On Wed, 06 Sep 2006 01:27:28 +0200, Matthew Raymond 
> <mattraymond at earthlink.net> wrote:
> 
>> Rimantas Liubertas wrote:
>> [Snip!]
>>> Chapter 30 "Using Dialogs" in "About the Face 2.0" [1] by Alan Cooper
>>> makes a good read too.
>>>
>>> [1] 
>>> http://www.amazon.com/About-Face-2-0-Essentials-Interaction/dp/0764526413/sr=8-1/qid=1157449548/ref=pd_bbs_1/102-1456987-0371351?ie=UTF8&s=books 
>>>
>>
>>
>>    So, what, we're supposed to order and read a book from Amazon.com in
>> order to know what you're talking about?
> 
> You could always go to a library. I believe the reference was offered as 
> something useful, should you be inclined to take the time.

But it would be even more useful if we got a short summary of _why_ the chapter 
is useful reading material and what point it contributes to the discussion. At 
the /very least/ something like:

Chapter 30 "Using Dialogs" in "About the Face 2.0" [1] by Alan Cooper makes a 
good read too. It explains that modal dialogs are never a good idea because they 
force the user to work on the computer's terms, rather than the other way 
around. It deals specifically with the issue of databases and suggests ways of 
designing the interface without resorting to user-hostile modal behaviour.

[note: that's all fiction, in case it wasn't obvious. I have no idea if that 
book has even been published in this country]

Even with a short description, you have to bear in mind that the book may not 
have widespread international distribution or may otherwise be hard to find.

-- 
"Eternity's a terrible thought. I mean, where's it all going to end?"
  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead


From mattraymond at earthlink.net  Wed Sep  6 11:46:52 2006
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Wed, 06 Sep 2006 14:46:52 -0400
Subject: [whatwg] Modal Dialog Box support
In-Reply-To: <op.tfgok4kfwxe0ny@widsith.local>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>	<BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>	<005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>	<5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com>	<44FE07E0.9080308@earthlink.net>
	<op.tfgok4kfwxe0ny@widsith.local>
Message-ID: <44FF179C.8040609@earthlink.net>

Charles McCathieNevile wrote:
>>    So, what, we're supposed to order and read a book from Amazon.com in
>> order to know what you're talking about?
> 
> You could always go to a library. I believe the reference was offered as  
> something useful, should you be inclined to take the time.

   There's three problems with this thinking:

1) Not everyone lives near a public library with a wide selection of
computer science books.

2) Not everyone has the time and the gasoline (which is expensive these
days) to go to the library every time someone references a book on a
mailing list.

3) Response to the email in question is delayed while the reader is
hunting for a book.

   James Graham was more tactful about this, and I suppose I could have
myself been a little more tactful to the person who posted the
Amazon.com link, but I want it to be clear that it's not acceptable for
someone to have to be well read to participate in this mailing list. As
such, your comment may be seen by some as elitist.


From anders.rundgren at telia.com  Wed Sep  6 11:54:54 2006
From: anders.rundgren at telia.com (Anders Rundgren)
Date: Wed, 6 Sep 2006 20:54:54 +0200
Subject: [whatwg] Modal Dialog Box support
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v><BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de><005f01c6d0cd$e9fb2020$82c5a8c0@arport2v><5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com><44FE07E0.9080308@earthlink.net>
	<op.tfgok4kfwxe0ny@widsith.local>
Message-ID: <005101c6d1e5$f1558ef0$82c5a8c0@arport2v>

I assume Opera and Mozilla will remove modality from alert () from
the next major releases?

People probably just can't wait to put their hands on a browser that will
finally free them from the Windows-style programming tyranny :-)

OEM vendors such as Opera should IMHO be a little bit cautious about
neglecting the [perceived] needs of the [somewhat uneducated] mainstream.
Fools may turn out as pretty good buyers!

thanx,
Anders Rundgren
Developer of legacy apps, but for the web

----- Original Message -----
From: "Charles McCathieNevile" <>
To: "Matthew Raymond" <mattraymond at earthlink.net>; "Rimantas Liubertas" <rimantas at gmail.com>
Cc: <whatwg at lists.whatwg.org>
Sent: Wednesday, September 06, 2006 16:44
Subject: Re: [whatwg] Modal Dialog Box support


On Wed, 06 Sep 2006 01:27:28 +0200, Matthew Raymond
<mattraymond at earthlink.net> wrote:

> Rimantas Liubertas wrote:
> [Snip!]
>> Chapter 30 "Using Dialogs" in "About the Face 2.0" [1] by Alan Cooper
>> makes a good read too.
>>
>> [1]
>>
http://www.amazon.com/About-Face-2-0-Essentials-Interaction/dp/0764526413/sr=8-1/qid=1157449548/ref=pd_bbs_1/102-1456987-0371351?ie=
UTF8&s=books
>
>
>    So, what, we're supposed to order and read a book from Amazon.com in
> order to know what you're talking about?

You could always go to a library. I believe the reference was offered as
something useful, should you be inclined to take the time.

Cheers

--
   Charles McCathieNevile, Opera Software: Standards Group
   hablo espa?ol  -  je parle fran?ais  -  jeg l?rer norsk
chaals at opera.com          Try Opera 9 now! http://opera.com




From chaals at opera.com  Wed Sep  6 12:54:05 2006
From: chaals at opera.com (Charles McCathieNevile)
Date: Wed, 06 Sep 2006 21:54:05 +0200
Subject: [whatwg] Books and rhetoric Re:  Modal Dialog Box support
In-Reply-To: <44FF179C.8040609@earthlink.net>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>
	<BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>
	<005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>
	<5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com>
	<44FE07E0.9080308@earthlink.net> <op.tfgok4kfwxe0ny@widsith.local>
	<44FF179C.8040609@earthlink.net>
Message-ID: <op.tfg2wfowwxe0ny@widsith.local>

On Wed, 06 Sep 2006 20:46:52 +0200, Matthew Raymond  
<mattraymond at earthlink.net> wrote:

> Charles McCathieNevile wrote:
>>>    So, what, we're supposed to order and read a book from Amazon.com in
>>> order to know what you're talking about?
>>
>> You could always go to a library. I believe the reference was offered as
>> something useful, should you be inclined to take the time.

Sorry if I was impolite. It was not my intention, but in any case I will  
make a bigger effort to be tactful.

> 1) Not everyone lives near a public library with a wide selection of
> computer science books.

Quite. Some people also have the luxury of a public library system that  
will if necessary ship books loaned from other libraries (librarians  
worked pretty hard to make systems like this work. t is a shame if people  
no longer realise what they have...).

> 2) Not everyone has the time and the gasoline (which is expensive these
> days) to go to the library every time someone references a book on a
> mailing list.

Naturally. The same as your point that not everyone can buy the book and  
read it.

> 3) Response to the email in question is delayed while the reader is
> hunting for a book.

Of course, if the discussion is based on the book to the extent that it is  
necessary to read it in order to take further part. (There are cases where  
that is justifiable, of course. Discussing the details of a piece of  
research without having read it is a bit pointless...)

>    James Graham was more tactful about this, and I suppose I could have
> myself been a little more tactful to the person who posted the
> Amazon.com link, but I want it to be clear that it's not acceptable for
> someone to have to be well read to participate in this mailing list. As
> such, your comment may be seen by some as elitist.

"something useful, should you be inclined to take the time" was meant to  
imply that it is not essential, but those who want to become ridiculously  
well-read? might find it interesting. My impression was that reading this  
book was not core to understanding the statement, just that it laid out  
what is presumably a similar argument in more detail.

Reductio ad absurdum (what you did, taking my argument to its logical  
extreme to show that it is of limited value) cuts both ways. There is no  
requirement that people know anything at all about the Web to participate  
on this list, although it would be a waste of almost everyone's time.

It strikes me as pretty obvious that being well read will increase the  
value of your contribution, and probably what you gain from this list as  
well. That does not mean you should read every book somone names, but nor  
should you expect people to restrict their statements to things that do  
not rely on any research that is only published in a form that requires  
payment (although good manners is, as James suggested, to at least  
summarise such information here for those who don't have a limitless  
book-buying budget and the spare time to sit and read every stray scrap  
that passes by).

I am quite content to be accused of saying that people who know more can  
better contribute. I do not at all subscribe to the idea that you must be  
ridiculously well-read? to participate, nor do you have to be so to have  
very valuable contributions to make. (Some people will criticise me  
whatever I say. Others will always agree and praise it. For the most part,  
neither of these groups are very interesting).

Cheers

Chaals

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo espa?ol  -  je parle fran?ais  -  jeg l?rer norsk
chaals at opera.com          Try Opera 9 now! http://opera.com


From mattraymond at earthlink.net  Wed Sep  6 19:39:36 2006
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Wed, 06 Sep 2006 22:39:36 -0400
Subject: [whatwg] Books and rhetoric Re:  Modal Dialog Box support
In-Reply-To: <op.tfg2wfowwxe0ny@widsith.local>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>
	<BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de>
	<005f01c6d0cd$e9fb2020$82c5a8c0@arport2v>
	<5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com>
	<44FE07E0.9080308@earthlink.net> <op.tfgok4kfwxe0ny@widsith.local>
	<44FF179C.8040609@earthlink.net> <op.tfg2wfowwxe0ny@widsith.local>
Message-ID: <44FF8668.7050109@earthlink.net>

Charles McCathieNevile wrote:
> On Wed, 06 Sep 2006 20:46:52 +0200, Matthew Raymond  
>> 3) Response to the email in question is delayed while the reader is
>> hunting for a book.
> 
> Of course, if the discussion is based on the book to the extent that it is  
> necessary to read it in order to take further part. (There are cases where  
> that is justifiable, of course. Discussing the details of a piece of  
> research without having read it is a bit pointless...)

   Rimantas's entire email was this:

   "Chapter 30 'Using Dialogs' in 'About the Face 2.0' by Alan Cooper
makes a good read too."

   There's nothing you can clearly determine about his meaning without
reading the book he refers to. That is not the same as a conversation
regarding the 9/ll Report, for instance, where you'll be specifically
talking about a literary source, because the thread is not about "About
the Face 2.0". Furthermore, I fail to see the value of limiting a public
conversation on standards because one or two people want to argue about
one book.

>>    James Graham was more tactful about this, and I suppose I could have
>> myself been a little more tactful to the person who posted the
>> Amazon.com link, but I want it to be clear that it's not acceptable for
>> someone to have to be well read to participate in this mailing list. As
>> such, your comment may be seen by some as elitist.
> 
> "something useful, should you be inclined to take the time" was meant to  
> imply that it is not essential, but those who want to become ridiculously  
> well-read? might find it interesting. My impression was that reading this  
> book was not core to understanding the statement, just that it laid out  
> what is presumably a similar argument in more detail.

   Upon reexamination of the email, he does appear to be making a casual
reference as you state. Hence my remark that I should have been more
tactful.

> Reductio ad absurdum (what you did, taking my argument to its logical  
> extreme to show that it is of limited value) cuts both ways. There is no  
> requirement that people know anything at all about the Web to participate  
> on this list, although it would be a waste of almost everyone's time.

   The difference here is that someone with little access to books can
still read web specifications and articles that are on the Internet.
There are two classifications of information here. The original
reference that started this conversation was to a book that you'd
probably have to mail order because it's not necessarily that common.
Contrast that with any specification on the W3C website and you can
clearly see that they differ greatly with regards to access. If you
refer to web content, a smart but uneducated person can quickly come up
to speed, whereas books take time to acquire, can be quite expensive in
some cases, and are not searchable.

> It strikes me as pretty obvious that being well read will increase the  
> value of your contribution, and probably what you gain from this list as  
> well. That does not mean you should read every book [someone] names, but nor  
> should you expect people to restrict their statements to things that do  
> not rely on any research that is only published in a form that requires  
> payment (although good manners is, as James suggested, to at least  
> summarise such information here for those who don't have a limitless  
> book-buying budget and the spare time to sit and read every stray scrap  
> that passes by).

   It wasn't just about good manners. If you go back and read the
message, you have no way of knowing what the author's position is on
modal dialogs unless you read the specified chapter of the book he
linked to. Not only could the author have made some statement about the
contents of the book, thus allowing us to understand both his position
and why we'd want to read the book, but under U.S. copyright law he
could have included a brief excerpt of the book's text as well.

   So this isn't just about manners. Referencing supporting material as
the sole means of communicating your argument serves a barrier to
further conversation and debate, even if the argument is offered in a
causal manner.

> I am quite content to be accused of saying that people who know more can  
> better contribute. I do not at all subscribe to the idea that you must be  
> ridiculously well-read? to participate, nor do you have to be so to have  
> very valuable contributions to make. (Some people will criticise me  
> whatever I say. Others will always agree and praise it. For the most part,  
> neither of these groups are very interesting).

   No message can please all the people all the time, but if the people
don't have the resources to devote to deciphering a message in the first
place, it won't matter if they like it or not because they'll never be
able to understand it. Encryption-by-book-reference is bad.


From ajvincent at gmail.com  Wed Sep  6 21:40:34 2006
From: ajvincent at gmail.com (Alex Vincent)
Date: Wed, 6 Sep 2006 21:40:34 -0700
Subject: [whatwg] WF2: required attribute clarification requested
Message-ID: <9301ed6b0609062140r372e8e6dq90b0b069bafacf7d@mail.gmail.com>

"For disabled or readonly controls, the (required) attribute has no effect."

What does this mean?  The missingValue bit of validityState is either
on or off.  Do I need to change the required bit if we're disabled?
Or should I leave it alone?

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001


From anders.rundgren at telia.com  Wed Sep  6 23:16:35 2006
From: anders.rundgren at telia.com (Anders Rundgren)
Date: Thu, 7 Sep 2006 08:16:35 +0200
Subject: [whatwg] HTLM5 - Addressing the Password Craze?
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v><BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de><005f01c6d0cd$e9fb2020$82c5a8c0@arport2v><5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com><44FE07E0.9080308@earthlink.net><op.tfgok4kfwxe0ny@widsith.local>
	<005101c6d1e5$f1558ef0$82c5a8c0@arport2v>
Message-ID: <004901c6d245$2c65e710$82c5a8c0@arport2v>

Dear all,
As you probably have noticed, practically every site offers a login.for their
members, customers, citizens etc. etc.

There are two problems here.
1.   User-id/password management has become a real nuisance. Once this was
an issue for computer professionals only, now it affects everyone from children
to grandma.

2. There are other and better authentication methods available that become hard
to migrate to without making life hard for end-users by asking them to use another
login method.  The site has no way of detecting the user's options.

It appears, that it may be possible to add some kind of negotiation/option
elements at the HTML level, that if supported by the underlying system could
offer a standardized and potentially more powerful version of the password
caches or external login form "hijacker software" that we currently use. 
Tentative functionality for the AHE (Authentication Helper Extension):

- Find out if the AHE is installed/available

- If the AHE is available, find out if the site in question is in the list

- If in the list, put out a dialog box giving the user an option to login, decline
  or manually enter login information. 

- If the site so requests, the user's authentication options (in case form based
  authentication was used) can be transferred during login, giving the site an
  option to ask/require the user to upgrade their authentication.  This could
  involve anything from digest-authentication to certificates.  The latter
  current lacks a decent provision method but there is some work 
  going on in this area as well.  MS CardSpaces is also an option.

- The authentication stuff would be possible to store in an USB token or
  even better in a mobile phone.  This is of course outside of HTML5
  but will be natural to support within 3-5 years from now.

- The scheme would (if properly implemented) be able to thwart phishing
  since a user-id/password (or other auth solution) could be tied to a
  SSL root + host name (or even better host domain).

In essence the desired result is a portable (mobile) multi-site authentication
 support mechanism that should not only make the web easier, but also
long-term considerably more secure.  

Other Options?
==========
The other option is addressing this problem at the transport level but I think
form-based authentication is a better entrance point since it is already in place.
There is no problem [at all] of having a mechanism [in the proposed scheme]
that switches from form-based authentication to transport-level authentication
like using TLS-client-certificates, while the opposite is impossible.

Sincerely
Anders Rundgren




From anders.rundgren at telia.com  Wed Sep  6 23:27:24 2006
From: anders.rundgren at telia.com (Anders Rundgren)
Date: Thu, 7 Sep 2006 08:27:24 +0200
Subject: [whatwg] HTML Was:HTLM5 - Addressing the Password Craze?
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v><BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de><005f01c6d0cd$e9fb2020$82c5a8c0@arport2v><5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com><44FE07E0.9080308@earthlink.net><op.tfgok4kfwxe0ny@widsith.local><005101c6d1e5$f1558ef0$82c5a8c0@arport2v>
	<004901c6d245$2c65e710$82c5a8c0@arport2v>
Message-ID: <006c01c6d246$aebaa8d0$82c5a8c0@arport2v>

Pardon,
I hope that you read the rest in spite of the fact that I screw-up already in the subject line. :-(
Please correct the spelling in answer threads.
Anders

----- Original Message ----- 
From: "Anders Rundgren" <anders.rundgren at telia.com>
To: <whatwg at lists.whatwg.org>
Cc: "Sam Hartman" <hartmans-ietf at mit.edu>
Sent: Thursday, September 07, 2006 08:16
Subject: [whatwg] HTLM5 - Addressing the Password Craze?


Dear all,
As you probably have noticed, practically every site offers a login.for their
members, customers, citizens etc. etc.

There are two problems here.
1.   User-id/password management has become a real nuisance. Once this was
an issue for computer professionals only, now it affects everyone from children
to grandma.

2. There are other and better authentication methods available that become hard
to migrate to without making life hard for end-users by asking them to use another
login method.  The site has no way of detecting the user's options.

It appears, that it may be possible to add some kind of negotiation/option
elements at the HTML level, that if supported by the underlying system could
offer a standardized and potentially more powerful version of the password
caches or external login form "hijacker software" that we currently use. 
Tentative functionality for the AHE (Authentication Helper Extension):

- Find out if the AHE is installed/available

- If the AHE is available, find out if the site in question is in the list

- If in the list, put out a dialog box giving the user an option to login, decline
  or manually enter login information. 

- If the site so requests, the user's authentication options (in case form based
  authentication was used) can be transferred during login, giving the site an
  option to ask/require the user to upgrade their authentication.  This could
  involve anything from digest-authentication to certificates.  The latter
  current lacks a decent provision method but there is some work 
  going on in this area as well.  MS CardSpaces is also an option.

- The authentication stuff would be possible to store in an USB token or
  even better in a mobile phone.  This is of course outside of HTML5
  but will be natural to support within 3-5 years from now.

- The scheme would (if properly implemented) be able to thwart phishing
  since a user-id/password (or other auth solution) could be tied to a
  SSL root + host name (or even better host domain).

In essence the desired result is a portable (mobile) multi-site authentication
 support mechanism that should not only make the web easier, but also
long-term considerably more secure.  

Other Options?
==========
The other option is addressing this problem at the transport level but I think
form-based authentication is a better entrance point since it is already in place.
There is no problem [at all] of having a mechanism [in the proposed scheme]
that switches from form-based authentication to transport-level authentication
like using TLS-client-certificates, while the opposite is impossible.

Sincerely
Anders Rundgren






From ian at hixie.ch  Thu Sep  7 07:27:46 2006
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 7 Sep 2006 07:27:46 -0700
Subject: [whatwg] WF2: required attribute clarification requested
In-Reply-To: <9301ed6b0609062140r372e8e6dq90b0b069bafacf7d@mail.gmail.com>
References: <9301ed6b0609062140r372e8e6dq90b0b069bafacf7d@mail.gmail.com>
Message-ID: <403d38e20609070727m3a0e77aet592c40c9f97be86a@mail.gmail.com>

I hear that this question is blocking implementation work so I'm going
to quickly reply to this despite being on holiday. :-)

On 9/6/06, Alex Vincent <ajvincent at gmail.com> wrote:
> "For disabled or readonly controls, the (required) attribute has no effect."
>
> What does this mean?

>From an implementor's point of view, it means nothing at all, because
it isn't a conformance statement (it has no "must", "should", "may",
etc) and isn't a definition (it doesn't define a term). Thus, for your
sake it can be ignored.

> The missingValue bit of validityState is either
> on or off.  Do I need to change the required bit if we're disabled?
> Or should I leave it alone?

missingValue, as defined, is unaffected by whether the control is
disabled or readonly -- it still gets set to true if the value is
missing -- but the control is not validated if it is disabled or
readonly, so it has no effect on submission, which is what I meant by
that sentence.

I'll clarify the spec when I get back from vacation. Right now it's
not very clear when the validity properties get set and when they
don't, which is unfortunate.

HTH,
-- 
Ian Hickson


From davebacher at hotmail.com  Thu Sep  7 17:38:36 2006
From: davebacher at hotmail.com (Dave Bacher)
Date: Thu, 07 Sep 2006 20:38:36 -0400
Subject: [whatwg] HTLM5 - Addressing the Password Craze?
In-Reply-To: <004901c6d245$2c65e710$82c5a8c0@arport2v>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v><BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de><005f01c6d0cd$e9fb2020$82c5a8c0@arport2v><5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com><44FE07E0.9080308@earthlink.net><op.tfgok4kfwxe0ny@widsith.local>	<005101c6d1e5$f1558ef0$82c5a8c0@arport2v>
	<004901c6d245$2c65e710$82c5a8c0@arport2v>
Message-ID: <BAY107-DAV151583511E2D4BFA7DAEDDC6370@phx.gbl>

Why not just issue a TLS 1 certificate?

Internet Explorer 2 and later support it.  Netscape Navigator 2 and 
later support it.  All versions of Opera support it.  All versions of 
FireFox support it.  All versions of Safari support it.  In fact, the 
vast majority of libraries and user agents that support TLS or even SSL 
websites also support TLS 1 client certificates.

When you issue the certificate, most browsers offer a convenient way to 
send it to the client.  It is installed into the local certificate 
store, or potentially a hardware device such as a smart card.  Later, 
the user authenticates to the user agent, and then is given the option 
of providing the certificate to a site that asks for it.  You can either 
issue a certificate specifically for your site, or you can have them go 
get a (freely available, in at least some cases) client certificate from 
a vendor like VeriSign.  These are typically called "e-mail signing 
certificates" or "digital ID's" by the companies that sell them.

There are a couple big benefits here.  First, you are using an existing 
user agent feature, that every user agent is likely to support.  So you 
just have to talk the user through installing the certificate into IE.

Secondly, web server side, it is a radio button in IIS 4 or later (not 
sure about earlier versions), or a single line in Apache to enable the 
feature.

Thirdly, if the ID becomes compromised, you can issue a revoke request, 
and issue a new ID.  This means the certificate that you issued before 
immediately becomes invalid, and so if the user loses the certificate or 
has it stollen, it takes no effort.

Fourthly, if the computer has a smart card reader (about USD $20) and a 
smart card, the certificate can be installed onto the smart card.  If 
this is done, then the user must provide a valid PIN in conjunction with 
the physical card in order to send data using the identities installed 
onto the card.  This adds a physical layer of security that is not 
possible with a name/password system.

And the worse problem than the number of systems using user id/password 
on a form to authenticate (and not at least using digest) is that many 
of these don't use TLS, and so the password is sent plain text or plain 
text equivalent across the network.  Additionally, many of these systems 
send the username and password pair by e-mail, which means not only is 
the user name and password sent across the internet, but also that it is 
stored in one or more well known locations on the user's computer for at 
least some period of time.  Since most operating systems don't provide 
any mechanism to lock down a directory so that only one module or 
application can access it, and since the most protection most user 
agents offer to e-mail files is the non-protection of a randomly 
generated file name, this is actually the worst part of the security risk.

Failing TLS, most servers (including IIS and Apache) and user agents 
support Kerberos, NTLM and a host of other options, and there are 
several publicly available specifications for what is called "Federated 
Identity."  The problem with all of these is that various parties have 
interests in pushing their own view of how a federated identity should 
work, usually to further their own goals.

Also, keep in mind that a federated identity system also poses privacy 
risks for the user.  When the user connects to your site, you must 
contact the federation and ask if they are who they say that they are.  
This means the federation knows both who you are, and what site you are 
trying to access.  This is why they aren't popular.

TLS doesn't have that problem, because you retrieve a certificate 
revocation list versus asking if a specific certificate is valid.  All 
that verisign (as an example) knows is that a TLS website asked for a 
revocation list, they don't ever know what user it was who was trying to 
access the site.

The issue with a federated log on is you must log on and log off from 
the federation site.  Sites have to check with that site to see if your 
token is valid or not, so any token based authentication inherently 
compromises your privacy (at least potentially).

Anders Rundgren wrote:
> Dear all,
> As you probably have noticed, practically every site offers a login.for their
> members, customers, citizens etc. etc.
>
> There are two problems here.
> 1.   User-id/password management has become a real nuisance. Once this was
> an issue for computer professionals only, now it affects everyone from children
> to grandma.
>
> 2. There are other and better authentication methods available that become hard
> to migrate to without making life hard for end-users by asking them to use another
> login method.  The site has no way of detecting the user's options.
>
> It appears, that it may be possible to add some kind of negotiation/option
> elements at the HTML level, that if supported by the underlying system could
> offer a standardized and potentially more powerful version of the password
> caches or external login form "hijacker software" that we currently use. 
> Tentative functionality for the AHE (Authentication Helper Extension):
>
> - Find out if the AHE is installed/available
>
> - If the AHE is available, find out if the site in question is in the list
>
> - If in the list, put out a dialog box giving the user an option to login, decline
>   or manually enter login information. 
>
> - If the site so requests, the user's authentication options (in case form based
>   authentication was used) can be transferred during login, giving the site an
>   option to ask/require the user to upgrade their authentication.  This could
>   involve anything from digest-authentication to certificates.  The latter
>   current lacks a decent provision method but there is some work 
>   going on in this area as well.  MS CardSpaces is also an option.
>
> - The authentication stuff would be possible to store in an USB token or
>   even better in a mobile phone.  This is of course outside of HTML5
>   but will be natural to support within 3-5 years from now.
>
> - The scheme would (if properly implemented) be able to thwart phishing
>   since a user-id/password (or other auth solution) could be tied to a
>   SSL root + host name (or even better host domain).
>
> In essence the desired result is a portable (mobile) multi-site authentication
>  support mechanism that should not only make the web easier, but also
> long-term considerably more secure.  
>
> Other Options?
> ==========
> The other option is addressing this problem at the transport level but I think
> form-based authentication is a better entrance point since it is already in place.
> There is no problem [at all] of having a mechanism [in the proposed scheme]
> that switches from form-based authentication to transport-level authentication
> like using TLS-client-certificates, while the opposite is impossible.
>
> Sincerely
> Anders Rundgren
>
>
>
>
>   






From dsr at w3.org  Fri Sep  8 09:40:34 2006
From: dsr at w3.org (Dave Raggett)
Date: Fri, 8 Sep 2006 17:40:34 +0100 (BST)
Subject: [whatwg] Hacking away on forms ... (fwd)
Message-ID: <Pine.LNX.4.64.0609081735250.5305@holly>

H&kon suggested I forward this to the whatwg list, so here goes.

  Dave Raggett <dsr at w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

---------- Forwarded message ----------
Date: Fri, 8 Sep 2006 16:38:50 +0100 (BST)
From: Dave Raggett <dsr at w3.org>
To: howcome at opera.com
Subject: Hacking away on forms ...

Hi H&kon,

I am hacking away at a cross platform JavaScript library for a 
forms-lite testbed, and hope to contribute to a compromise between 
the WebForms 2.0 and XForms camps. It seems to me that there is an 
opportunity to provide an incremental enhancement to HTML4 forms, 
that is easy to learn, reduces the amount of scripting authors have 
to do, and importantly, is a smooth stepping stone towards the use 
of XForms. What follows is an overview of what I am implementing. 
The testbed will be available in October (I am travelling too much 
in September).

The changes to the input element largely reflect what is in WF2 with 
some additions designed to reduce the need for authors to write 
client side scripts. The validate attribute is a boolean expression 
over fields names. If the value doesn't match the type and validate 
attributes the "invalid" class value is set on the element and may 
be used to alter the styling. The requires attribute is a boolean 
expression like validate, and indicates a value is required. As an 
example, you might be asked to give the name of a guardian if you 
said that your age is under 15. The required attribute could also be 
used on div elements to reveal/hide groups of controls (via an 
associated class value). You can also designate div and fieldset 
elements as repeating groups of controls. The index for a repeated 
group may be used within expressions for constraints within and 
across groups.

A major difference from WF2 is the use of the model-view-controller 
design pattern. The input elements act as presentations with the 
model held as JavaScript objects. This allows for multiple views to 
be kept in sync, as well as orchestrating updates to output fields. 
The getters and setters are associated with the field types, and the 
set of types can be extended by authors if needed. The model is 
automatically determined from the input elements and greatly reduces 
the amount of markup compared with XForms.

p.s. implementing the output element would be a lot cleaner if more 
browsers supported the /> syntax for empty elements that aren't part 
of traditional HTML. IE already does so, but Firefox and Opera do 
not. Firefox is even worse as it coerces the tag name to upper case 
when you inspect the DOM node it creates! Opera and Firefox also 
differ over the amount of whitespace text nodes that are set as the 
content on unknown elements. IE has its own weird worts, although 
strangely, it works rather nicely for non-html markup in XML 
namespaces. IE therefore encourages the use of XML namespaces for 
mixed markup when delivered as text/html.


From staikos at kde.org  Thu Sep  7 23:45:31 2006
From: staikos at kde.org (George Staikos)
Date: Fri, 8 Sep 2006 02:45:31 -0400
Subject: [whatwg] HTLM5 - Addressing the Password Craze?
In-Reply-To: <BAY107-DAV151583511E2D4BFA7DAEDDC6370@phx.gbl>
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v>
	<004901c6d245$2c65e710$82c5a8c0@arport2v>
	<BAY107-DAV151583511E2D4BFA7DAEDDC6370@phx.gbl>
Message-ID: <200609080245.31869.staikos@kde.org>


I would like to add a few more points here.

1) The hardware is very cumbersome.  It's not pervasive, it requires carrying 
cards and tokens, and limits mobility.
2) Certificates are more easily stolen than passwords unless the certificates 
have passwords on them.  Then, well, we are using passwords again.  
Certificates have lost most of their value by this point I think.
3) Users just don't understand this stuff yet.  In the case of a system 
failure most users will be completely lost with how to recover.
4) People are aware of the vulnerabilities of passwords and take at least some 
reasonable precautions with them.  Certificates are not infallible and people 
are not aware of how to properly protect them.

  Simplicity is golden here, as long as we don't truly compromise security.  I 
don't think passwords are necessarily a compromise of security.  At least not 
in contrast to TLS certificates (which I personally believe are a great 
technology).

On Thursday 07 September 2006 20:38, Dave Bacher wrote:
> Why not just issue a TLS 1 certificate?
>
> Internet Explorer 2 and later support it.  Netscape Navigator 2 and
> later support it.  All versions of Opera support it.  All versions of
> FireFox support it.  All versions of Safari support it.  In fact, the
> vast majority of libraries and user agents that support TLS or even SSL
> websites also support TLS 1 client certificates.
>
> When you issue the certificate, most browsers offer a convenient way to
> send it to the client.  It is installed into the local certificate
> store, or potentially a hardware device such as a smart card.  Later,
> the user authenticates to the user agent, and then is given the option
> of providing the certificate to a site that asks for it.  You can either
> issue a certificate specifically for your site, or you can have them go
> get a (freely available, in at least some cases) client certificate from
> a vendor like VeriSign.  These are typically called "e-mail signing
> certificates" or "digital ID's" by the companies that sell them.
>
> There are a couple big benefits here.  First, you are using an existing
> user agent feature, that every user agent is likely to support.  So you
> just have to talk the user through installing the certificate into IE.
>
> Secondly, web server side, it is a radio button in IIS 4 or later (not
> sure about earlier versions), or a single line in Apache to enable the
> feature.
>
> Thirdly, if the ID becomes compromised, you can issue a revoke request,
> and issue a new ID.  This means the certificate that you issued before
> immediately becomes invalid, and so if the user loses the certificate or
> has it stollen, it takes no effort.
>
> Fourthly, if the computer has a smart card reader (about USD $20) and a
> smart card, the certificate can be installed onto the smart card.  If
> this is done, then the user must provide a valid PIN in conjunction with
> the physical card in order to send data using the identities installed
> onto the card.  This adds a physical layer of security that is not
> possible with a name/password system.
>
> And the worse problem than the number of systems using user id/password
> on a form to authenticate (and not at least using digest) is that many
> of these don't use TLS, and so the password is sent plain text or plain
> text equivalent across the network.  Additionally, many of these systems
> send the username and password pair by e-mail, which means not only is
> the user name and password sent across the internet, but also that it is
> stored in one or more well known locations on the user's computer for at
> least some period of time.  Since most operating systems don't provide
> any mechanism to lock down a directory so that only one module or
> application can access it, and since the most protection most user
> agents offer to e-mail files is the non-protection of a randomly
> generated file name, this is actually the worst part of the security risk.
>
> Failing TLS, most servers (including IIS and Apache) and user agents
> support Kerberos, NTLM and a host of other options, and there are
> several publicly available specifications for what is called "Federated
> Identity."  The problem with all of these is that various parties have
> interests in pushing their own view of how a federated identity should
> work, usually to further their own goals.
>
> Also, keep in mind that a federated identity system also poses privacy
> risks for the user.  When the user connects to your site, you must
> contact the federation and ask if they are who they say that they are.
> This means the federation knows both who you are, and what site you are
> trying to access.  This is why they aren't popular.
>
> TLS doesn't have that problem, because you retrieve a certificate
> revocation list versus asking if a specific certificate is valid.  All
> that verisign (as an example) knows is that a TLS website asked for a
> revocation list, they don't ever know what user it was who was trying to
> access the site.
>
> The issue with a federated log on is you must log on and log off from
> the federation site.  Sites have to check with that site to see if your
> token is valid or not, so any token based authentication inherently
> compromises your privacy (at least potentially).
>
> Anders Rundgren wrote:
> > Dear all,
> > As you probably have noticed, practically every site offers a login.for
> > their members, customers, citizens etc. etc.
> >
> > There are two problems here.
> > 1.   User-id/password management has become a real nuisance. Once this
> > was an issue for computer professionals only, now it affects everyone
> > from children to grandma.
> >
> > 2. There are other and better authentication methods available that
> > become hard to migrate to without making life hard for end-users by
> > asking them to use another login method.  The site has no way of
> > detecting the user's options.
> >
> > It appears, that it may be possible to add some kind of
> > negotiation/option elements at the HTML level, that if supported by the
> > underlying system could offer a standardized and potentially more
> > powerful version of the password caches or external login form "hijacker
> > software" that we currently use. Tentative functionality for the AHE
> > (Authentication Helper Extension):
> >
> > - Find out if the AHE is installed/available
> >
> > - If the AHE is available, find out if the site in question is in the
> > list
> >
> > - If in the list, put out a dialog box giving the user an option to
> > login, decline or manually enter login information.
> >
> > - If the site so requests, the user's authentication options (in case
> > form based authentication was used) can be transferred during login,
> > giving the site an option to ask/require the user to upgrade their
> > authentication.  This could involve anything from digest-authentication
> > to certificates.  The latter current lacks a decent provision method but
> > there is some work going on in this area as well.  MS CardSpaces is also
> > an option.
> >
> > - The authentication stuff would be possible to store in an USB token or
> >   even better in a mobile phone.  This is of course outside of HTML5
> >   but will be natural to support within 3-5 years from now.
> >
> > - The scheme would (if properly implemented) be able to thwart phishing
> >   since a user-id/password (or other auth solution) could be tied to a
> >   SSL root + host name (or even better host domain).
> >
> > In essence the desired result is a portable (mobile) multi-site
> > authentication support mechanism that should not only make the web
> > easier, but also long-term considerably more secure.
> >
> > Other Options?
> > ==========
> > The other option is addressing this problem at the transport level but I
> > think form-based authentication is a better entrance point since it is
> > already in place. There is no problem [at all] of having a mechanism [in
> > the proposed scheme] that switches from form-based authentication to
> > transport-level authentication like using TLS-client-certificates, while
> > the opposite is impossible.
> >
> > Sincerely
> > Anders Rundgren

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/



From ben at benmeadowcroft.com  Fri Sep  8 16:00:01 2006
From: ben at benmeadowcroft.com (Ben Meadowcroft)
Date: Sat, 9 Sep 2006 00:00:01 +0100
Subject: [whatwg] HTLM5 - Addressing the Password Craze?
In-Reply-To: <200609080245.31869.staikos@kde.org>
Message-ID: <008701c6d39a$87f39630$0202a8c0@BensPC>



> -----Original Message-----
> From: George Staikos
> I would like to add a few more points here.
> 
> 2) Certificates are more easily stolen than passwords unless 
> the certificates 
> have passwords on them.  Then, well, we are using passwords again.  
> Certificates have lost most of their value by this point I think.

But you usually can't get someones certificate by offering a mars bar on
the street...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3088 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20060909/d8dbb14a/attachment-0001.bin>

From anders.rundgren at telia.com  Fri Sep  8 23:41:22 2006
From: anders.rundgren at telia.com (Anders Rundgren)
Date: Sat, 9 Sep 2006 08:41:22 +0200
Subject: [whatwg] Certificates & Browsers. Was:] HTML5 - Addressing the
	Password Craze?
References: <01bb01c6cf2a$fd881d90$82c5a8c0@arport2v><BFF7A940-2439-440C-B630-B04FFB59FFDB@crissov.de><005f01c6d0cd$e9fb2020$82c5a8c0@arport2v><5ccfb3340609050246u3a5f15d9vb3fb2d63326ce1a9@mail.gmail.com><44FE07E0.9080308@earthlink.net><op.tfgok4kfwxe0ny@widsith.local>	<005101c6d1e5$f1558ef0$82c5a8c0@arport2v><004901c6d245$2c65e710$82c5a8c0@arport2v>
	<BAY107-DAV151583511E2D4BFA7DAEDDC6370@phx.gbl>
Message-ID: <005101c6d3da$f735b060$82c5a8c0@arport2v>

Hi David,
Thank you for your elaborate replay although you did not really
comment on my proposal but rather proposed something else.

>Why not just issue a TLS 1 certificate?

I agree with all you things you say about this technology but let me
begin with another, for the WHATWG applicable comment:

==================================================
  The "standards" for PKI provisioning using browsers are in a real mess.
  Xenroll, KeyGen and a JavaScript CRMF do not really make this
  part as simple as it must be in order to challenge passwords.
==================================================

Anyway, my proposal was about offering a "migration path" to other
authentication schemes, as well as improving the current de-facto standard.

Regarding certificates: the provisioning, mobility and pretty proprietary
card schemes (like no preinstalled drivers in Windows) will make this
transition period rather long.  That none of the browser vendors support
digital signatures (in a reasonable way), is another reason why PKI
deployment is hampered.

Personally, I believe PKI will stay marginal [*] until you can keep your IDs
in a mobile phone.  The US PIV card (to take an example), only allows
you to keep a single Federal ID which is not particularly useful for the
Internet where you will continue to have multiple and mostly entirely
independent IDs.

thanx
Anders

*] There are 10M+ of citizens certificates in Europe, but you cannot
use them at particularly many places due to the problems cited.

////
Internet Explorer 2 and later support it.  Netscape Navigator 2 and 
later support it.  All versions of Opera support it.  All versions of 
FireFox support it.  All versions of Safari support it.  In fact, the 
vast majority of libraries and user agents that support TLS or even SSL 
websites also support TLS 1 client certificates.

When you issue the certificate, most browsers offer a convenient way to 
send it to the client.  It is installed into the local certificate 
store, or potentially a hardware device such as a smart card.  Later, 
the user authenticates to the user agent, and then is given the option 
of providing the certificate to a site that asks for it.  You can either 
issue a certificate specifically for your site, or you can have them go 
get a (freely available, in at least some cases) client certificate from 
a vendor like VeriSign.  These are typically called "e-mail signing 
certificates" or "digital ID's" by the companies that sell them.

There are a couple big benefits here.  First, you are using an existing 
user agent feature, that every user agent is likely to support.  So you 
just have to talk the user through installing the certificate into IE.

Secondly, web server side, it is a radio button in IIS 4 or later (not 
sure about earlier versions), or a single line in Apache to enable the 
feature.

Thirdly, if the ID becomes compromised, you can issue a revoke request, 
and issue a new ID.  This means the certificate that you issued before 
immediately becomes invalid, and so if the user loses the certificate or 
has it stollen, it takes no effort.

Fourthly, if the computer has a smart card reader (about USD $20) and a 
smart card, the certificate can be installed onto the smart card.  If 
this is done, then the user must provide a valid PIN in conjunction with 
the physical card in order to send data using the identities installed 
onto the card.  This adds a physical layer of security that is not 
possible with a name/password system.

And the worse problem than the number of systems using user id/password 
on a form to authenticate (and not at least using digest) is that many 
of these don't use TLS, and so the password is sent plain text or plain 
text equivalent across the network.  Additionally, many of these systems 
send the username and password pair by e-mail, which means not only is 
the user name and password sent across the internet, but also that it is 
stored in one or more well known locations on the user's computer for at 
least some period of time.  Since most operating systems don't provide 
any mechanism to lock down a directory so that only one module or 
application can access it, and since the most protection most user 
agents offer to e-mail files is the non-protection of a randomly 
generated file name, this is actually the worst part of the security risk.

Failing TLS, most servers (including IIS and Apache) and user agents 
support Kerberos, NTLM and a host of other options, and there are 
several publicly available specifications for what is called "Federated 
Identity."  The problem with all of these is that various parties have 
interests in pushing their own view of how a federated identity should 
work, usually to further their own goals.

Also, keep in mind that a federated identity system also poses privacy 
risks for the user.  When the user connects to your site, you must 
contact the federation and ask if they are who they say that they are.  
This means the federation knows both who you are, and what site you are 
trying to access.  This is why they aren't popular.

TLS doesn't have that problem, because you retrieve a certificate 
revocation list versus asking if a specific certificate is valid.  All 
that verisign (as an example) knows is that a TLS website asked for a 
revocation list, they don't ever know what user it was who was trying to 
access the site.

The issue with a federated log on is you must log on and log off from 
the federation site.  Sites have to check with that site to see if your 
token is valid or not, so any token based authentication inherently 
compromises your privacy (at least potentially).

Anders Rundgren wrote:
> Dear all,
> As you probably have noticed, practically every site offers a login.for their
> members, customers, citizens etc. etc.
>
> There are two problems here.
> 1.   User-id/password management has become a real nuisance. Once this was
> an issue for computer professionals only, now it affects everyone from children
> to grandma.
>
> 2. There are other and better authentication methods available that become hard
> to migrate to without making life hard for end-users by asking them to use another
> login method.  The site has no way of detecting the user's options.
>
> It appears, that it may be possible to add some kind of negotiation/option
> elements at the HTML level, that if supported by the underlying system could
> offer a standardized and potentially more powerful version of the password
> caches or external login form "hijacker software" that we currently use. 
> Tentative functionality for the AHE (Authentication Helper Extension):
>
> - Find out if the AHE is installed/available
>
> - If the AHE is available, find out if the site in question is in the list
>
> - If in the list, put out a dialog box giving the user an option to login, decline
>   or manually enter login information. 
>
> - If the site so requests, the user's authentication options (in case form based
>   authentication was used) can be transferred during login, giving the site an
>   option to ask/require the user to upgrade their authentication.  This could
>   involve anything from digest-authentication to certificates.  The latter
>   current lacks a decent provision method but there is some work 
>   going on in this area as well.  MS CardSpaces is also an option.
>
> - The authentication stuff would be possible to store in an USB token or
>   even better in a mobile phone.  This is of course outside of HTML5
>   but will be natural to support within 3-5 years from now.
>
> - The scheme would (if properly implemented) be able to thwart phishing
>   since a user-id/password (or other auth solution) could be tied to a
>   SSL root + host name (or even better host domain).
>
> In essence the desired result is a portable (mobile) multi-site authentication
>  support mechanism that should not only make the web easier, but also
> long-term considerably more secure.  
>
> Other Options?
> ==========
> The other option is addressing this problem at the transport level but I think
> form-based authentication is a better entrance point since it is already in place.
> There is no problem [at all] of having a mechanism [in the proposed scheme]
> that switches from form-based authentication to transport-level authentication
> like using TLS-client-certificates, while the opposite is impossible.
>
> Sincerely
> Anders Rundgren
>
>
>
>
>   







From staikos at kde.org  Fri Sep  8 18:35:06 2006
From: staikos at kde.org (George Staikos)
Date: Fri, 8 Sep 2006 21:35:06 -0400
Subject: [whatwg] HTLM5 - Addressing the Password Craze?
In-Reply-To: <008701c6d39a$87f39630$0202a8c0@BensPC>
References: <008701c6d39a$87f39630$0202a8c0@BensPC>
Message-ID: <200609082135.06437.staikos@kde.org>

On Friday 08 September 2006 19:00, Ben Meadowcroft wrote:
> > -----Original Message-----
> > From: George Staikos
> > I would like to add a few more points here.
> >
> > 2) Certificates are more easily stolen than passwords unless
> > the certificates
> > have passwords on them.  Then, well, we are using passwords again.
> > Certificates have lost most of their value by this point I think.
>
> But you usually can't get someones certificate by offering a mars bar on
> the street...

   Do you have evidence that this is any different than the password case?

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/



From fora at annevankesteren.nl  Sat Sep  9 09:00:15 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Sat, 09 Sep 2006 18:00:15 +0200
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <Pine.LNX.4.64.0609081735250.5305@holly>
References: <Pine.LNX.4.64.0609081735250.5305@holly>
Message-ID: <op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>

On Fri, 08 Sep 2006 18:40:34 +0200, Dave Raggett <dsr at w3.org> wrote:
> p.s. implementing the output element would be a lot cleaner if more  
> browsers supported the /> syntax for empty elements that aren't part of  
> traditional HTML. IE already does so, but Firefox and Opera do not.  
> Firefox is even worse as it coerces the tag name to upper case when you  
> inspect the DOM node it creates! Opera and Firefox also differ over the  
> amount of whitespace text nodes that are set as the content on unknown  
> elements. IE has its own weird worts, although strangely, it works  
> rather nicely for non-html markup in XML namespaces. IE therefore  
> encourages the use of XML namespaces for mixed markup when delivered as  
> text/html.

You sure IE only does this for <foo/> and not also for <foo>? It's my  
understand they are treated as being identical in every single browser.  
Whether or not such an element is treated as empty varies from browser to  
browser.

Converting the node name to uppercase also seems like the right thing to  
do for text/html documents although HTML5 might change bits of that...


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From dsr at w3.org  Sun Sep 10 03:17:19 2006
From: dsr at w3.org (Dave Raggett)
Date: Sun, 10 Sep 2006 11:17:19 +0100 (BST)
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>
References: <Pine.LNX.4.64.0609081735250.5305@holly>
	<op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>
Message-ID: <Pine.LNX.4.64.0609101045340.5363@holly>

On Sat, 9 Sep 2006, Anne van Kesteren wrote:

> On Fri, 08 Sep 2006 18:40:34 +0200, Dave Raggett <dsr at w3.org> wrote:
>> p.s. implementing the output element would be a lot cleaner if 
>> more browsers supported the /> syntax for empty elements that 
>> aren't part of traditional HTML. IE already does so, but Firefox 
>> and Opera do not. Firefox is even worse as it coerces the tag 
>> name to upper case when you inspect the DOM node it creates! 
>> Opera and Firefox also differ over the amount of whitespace text 
>> nodes that are set as the content on unknown elements. IE has its 
>> own weird worts, although strangely, it works rather nicely for 
>> non-html markup in XML namespaces. IE therefore encourages the 
>> use of XML namespaces for mixed markup when delivered as 
>> text/html.
>
> You sure IE only does this for <foo/> and not also for <foo>? It's 
> my understand they are treated as being identical in every single 
> browser. Whether or not such an element is treated as empty varies 
> from browser to browser.

For traditional HTML elements, IE uses its built-in knowledge of
their content model, along with rules for dealing with malformed
HTML markup.

For other elements the behavior depends upon whether the tag
has a namespace prefix or not.

If the tag doesn't have an XML namespace prefix, then it is
inserted into the DOM as an empty upper case element.

   <foo>     nodeName = "FOO"
   </foo>    nodeName = "/FOO"
   <foo/>    nodeName = "FOO"

The same is true if you define the XML namespace with the
xmlns attribute e.g.

   <foo xmlns="http://example.com/ns"/>  nodeName="FOO"

BUT if you use a tag with a previously defined XML namespace
then things are different:

   <f:foo>hello world</f:foo>

is parsed as a foo element with a text node "hello world" as its
content. The case for the element's tag name is preserved.

if the namespace prefix isn't previously declared then you get:

   <f:foo>    nodeName = "F:FOO"
   </f:foo>   nodeName = "/F:FOO"

However, the namespace declaration can leave the URI empty, e.g.

  <html xmlns:f="">

is sufficient for IE to avoid giving <f:foo> the empty uppercase
treatment.

It isn't sufficient to define the namespace on the element itself
as in the following example:

   <g:fred xmlns:g="">smith</g:fred>

which gets the uppercase empty element treatment. To avoid
that, you need to declare the namespace on the html start tag.

Elements with a declared XML namespace prefix can be styled
with CSS.

Note that my tests were done using a script to walk the DOM
tree and display the results in an alert box.

With a knowledge of the above behavior, web page scripts can
be written clean up the DOM, e.g. placing the tags into the
HTML namespace with a dynamically defined prefix, and fixing
up the content. It's not a show stopper.

> Converting the node name to uppercase also seems like the right 
> thing to do for text/html documents although HTML5 might change 
> bits of that...

Perhaps.

Another difference between IE and Opera is that Opera includes
the prefix as part of the node name for elements with a previously
declared XML namespace.

None of this is insurmountable by a determined scripter, but we
might perhaps try and aim for closer alignment amongst different 
browsers that is currently the case. I am not advocating that
Opera follows IE's upper case/empty element weirdness, rather
that Opera treat <foo/> as an empty element.

  Dave Raggett <dsr at w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)


From hasather at gmail.com  Sun Sep 10 03:35:25 2006
From: hasather at gmail.com (=?ISO-8859-1?Q?David_H=E5s=E4ther?=)
Date: Sun, 10 Sep 2006 12:35:25 +0200
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <Pine.LNX.4.64.0609101045340.5363@holly>
References: <Pine.LNX.4.64.0609081735250.5305@holly>	<op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.64.0609101045340.5363@holly>
Message-ID: <4503EA6D.6020408@gmail.com>

On 2006-09-10 12:17, Dave Raggett wrote:
> On Sat, 9 Sep 2006, Anne van Kesteren wrote:
>> You sure IE only does this for <foo/> and not also for <foo>? It's my
>> understand they are treated as being identical in every single
>> browser. Whether or not such an element is treated as empty varies
>> from browser to browser.
> 
> For traditional HTML elements, IE uses its built-in knowledge of
> their content model, along with rules for dealing with malformed
> HTML markup.
> 
> For other elements the behavior depends upon whether the tag
> has a namespace prefix or not.
> 
> If the tag doesn't have an XML namespace prefix, then it is
> inserted into the DOM as an empty upper case element.
> 
>   <foo>     nodeName = "FOO"
>   </foo>    nodeName = "/FOO"
>   <foo/>    nodeName = "FOO"

What does tags have to do with the DOM?

-- 
David H?s?ther


From monterro2004 at tiscali.co.uk  Sun Sep 10 03:41:51 2006
From: monterro2004 at tiscali.co.uk (Francisco Monteiro)
Date: Sun, 10 Sep 2006 11:41:51 +0100
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <4503EA6D.6020408@gmail.com>
Message-ID: <021701c6d4c5$ba2c5070$0500a8c0@computername>

>What does tags have to do with the DOM?

Exactly, is this thread becoming a Opera marketing ploy?

Francisco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3210 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20060910/0f00d4e4/attachment-0001.bin>

From fora at annevankesteren.nl  Sun Sep 10 03:47:42 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Sun, 10 Sep 2006 12:47:42 +0200
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <021701c6d4c5$ba2c5070$0500a8c0@computername>
References: <021701c6d4c5$ba2c5070$0500a8c0@computername>
Message-ID: <op.tfnr9s06aw9dld@id-c0020.oslo.opera.com>

On Sun, 10 Sep 2006 12:41:51 +0200, Francisco Monteiro  
<monterro2004 at tiscali.co.uk> wrote:
>> What does tags have to do with the DOM?
>
> Exactly, is this thread becoming a Opera marketing ploy?

?


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From lachlan.hunt at lachy.id.au  Sun Sep 10 03:47:47 2006
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Sun, 10 Sep 2006 20:47:47 +1000
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <Pine.LNX.4.64.0609101045340.5363@holly>
References: <Pine.LNX.4.64.0609081735250.5305@holly>	<op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.64.0609101045340.5363@holly>
Message-ID: <4503ED53.4070304@lachy.id.au>

Dave Raggett wrote:
> For traditional HTML elements, IE uses its built-in knowledge of
> their content model, along with rules for dealing with malformed
> HTML markup.
> 
> For other elements the behavior depends upon whether the tag
> has a namespace prefix or not.
> 
> If the tag doesn't have an XML namespace prefix, then it is
> inserted into the DOM as an empty upper case element.
> 
>   <foo>     nodeName = "FOO"
>   </foo>    nodeName = "/FOO"
>   <foo/>    nodeName = "FOO"
> 
> The same is true if you define the XML namespace with the
> xmlns attribute e.g.
> 
>   <foo xmlns="http://example.com/ns"/>  nodeName="FOO"

So far, that's correct.

> BUT if you use a tag with a previously defined XML namespace
> then things are different:
> 
>   <f:foo>hello world</f:foo>
> 
> is parsed as a foo element with a text node "hello world" as its
> content. The case for the element's tag name is preserved.


My tests show that the namespace does not have to be previously 
decalred, the results (as far as the tagName is concerned) are the same 
either way.

> if the namespace prefix isn't previously declared then you get:
> 
>   <f:foo>    nodeName = "F:FOO"
>   </f:foo>   nodeName = "/F:FOO"

Please publish a test case demonstrating this.  My tests show the same 
result is achieved regardless of whether the namespace is declared.

> It isn't sufficient to define the namespace on the element itself
> as in the following example:
> 
>   <g:fred xmlns:g="">smith</g:fred>
> 
> which gets the uppercase empty element treatment.

That's not what I get either.  My tests showed the tag name in lowercase.

> Elements with a declared XML namespace prefix can be styled
> with CSS.

How can the be styled in a way that is affected by the namespace 
declaration?  My tests show that the only way to style such an element 
is like the following and it will apply regardless of whether its 
namespace is declared.

f\:foo { background: green; }

<f:foo>test</f:foo>

> Note that my tests were done using a script to walk the DOM
> tree and display the results in an alert box.

My tests were done using your supplied sample markup and the Live DOM 
Viewer, which uses a similar approach.

http://software.hixie.ch/utilities/js/live-dom-viewer/

> None of this is insurmountable by a determined scripter, but we
> might perhaps try and aim for closer alignment amongst different 
> browsers that is currently the case. I am not advocating that
> Opera follows IE's upper case/empty element weirdness, rather
> that Opera treat <foo/> as an empty element.

How about we just forget about the crazy notion of introducing 
pseudo-XML syntax and handling into HTML.  If XHTML really is the future 
(as many people, including myself, have claimed), then we really don't 
want to destroy it by allowing it to be used and abused like HTML?the 
very thing it was designed to replace!

Please provide test cases demonstrating every result you obtained, 
especially where my tests have given different results.

-- 
Lachlan Hunt
http://lachy.id.au/


From lachlan.hunt at lachy.id.au  Sun Sep 10 03:50:58 2006
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Sun, 10 Sep 2006 20:50:58 +1000
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <021701c6d4c5$ba2c5070$0500a8c0@computername>
References: <021701c6d4c5$ba2c5070$0500a8c0@computername>
Message-ID: <4503EE12.1070509@lachy.id.au>

Francisco Monteiro wrote:
>> What does tags have to do with the DOM?

We're talking about the DOM that IE produces when given specific markup. 
  It has everything to do with the DOM!

> Exactly, is this thread becoming a Opera marketing ploy?

What the...?

-- 
Lachlan Hunt
http://lachy.id.au/


From hasather at gmail.com  Sun Sep 10 03:56:35 2006
From: hasather at gmail.com (=?UTF-8?B?RGF2aWQgSMOlc8OkdGhlcg==?=)
Date: Sun, 10 Sep 2006 12:56:35 +0200
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <4503EE12.1070509@lachy.id.au>
References: <021701c6d4c5$ba2c5070$0500a8c0@computername>
	<4503EE12.1070509@lachy.id.au>
Message-ID: <4503EF63.3060403@gmail.com>

On 2006-09-10 12:50, Lachlan Hunt wrote:
> Francisco Monteiro wrote:
>>> What does tags have to do with the DOM?
> 
> We're talking about the DOM that IE produces when given specific markup.

Sorry for not following the whole discussion.

>> Exactly, is this thread becoming a Opera marketing ploy?
> 
> What the...?

Exactly.

-- 
David H?s?ther


From dsr at w3.org  Sun Sep 10 05:19:02 2006
From: dsr at w3.org (Dave Raggett)
Date: Sun, 10 Sep 2006 13:19:02 +0100 (BST)
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <4503ED53.4070304@lachy.id.au>
References: <Pine.LNX.4.64.0609081735250.5305@holly>
	<op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.64.0609101045340.5363@holly> <4503ED53.4070304@lachy.id.au>
Message-ID: <Pine.LNX.4.64.0609101241030.5348@holly>

You can reproduce my tests by pointing your browser at:

   http://people.w3.org/~dsr/dom/test.html

This will display an alert box with a representation of the
DOM tree showing element and text nodes but not attributes.
The string value from the node's nodeName property are shown
within single quotemarks.

You can then use view source to look at the source markup. Let
me know if you want to create some more tests. For example, it's 
possible that the results will vary according to whether IE is in 
quirks mode or not.

With regards to the CSS tests:

On IE the only word to be highlighted is the second "jones".
The CSS rules in the style sheet are not applied by IE to the
first and third instances of the fred element.

On Opera and Firefox, all three instances are higlighted.

With regards to the parsing tests, I presume that Opera shows
output in uppercase because it thinks it is part of the
predefined html tag set as Anne suggested.

  Dave Raggett <dsr at w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)


From danbri at danbri.org  Sun Sep 10 05:35:09 2006
From: danbri at danbri.org (Dan Brickley)
Date: Sun, 10 Sep 2006 13:35:09 +0100
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <4503EF63.3060403@gmail.com>
References: <021701c6d4c5$ba2c5070$0500a8c0@computername>	<4503EE12.1070509@lachy.id.au>
	<4503EF63.3060403@gmail.com>
Message-ID: <4504067D.5060402@danbri.org>

David H?s?ther wrote:
> On 2006-09-10 12:50, Lachlan Hunt wrote:
>> Francisco Monteiro wrote:
>>>> What does tags have to do with the DOM?
>> We're talking about the DOM that IE produces when given specific markup.
> 
> Sorry for not following the whole discussion.
> 
>>> Exactly, is this thread becoming a Opera marketing ploy?
>> What the...?
> 
> Exactly.

While we're at it... I was wondering what's best: Windows or MacOS X...?

Dan



From fora at annevankesteren.nl  Sun Sep 10 05:34:01 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Sun, 10 Sep 2006 14:34:01 +0200
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <Pine.LNX.4.64.0609101241030.5348@holly>
References: <Pine.LNX.4.64.0609081735250.5305@holly>
	<op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.64.0609101045340.5363@holly>
	<4503ED53.4070304@lachy.id.au>
	<Pine.LNX.4.64.0609101241030.5348@holly>
Message-ID: <op.tfnw6zpwaw9dld@id-c0020.oslo.opera.com>

On Sun, 10 Sep 2006 14:19:02 +0200, Dave Raggett <dsr at w3.org> wrote:
> You can then use view source to look at the source markup. Let
> me know if you want to create some more tests. For example, it's  
> possible that the results will vary according to whether IE is in quirks  
> mode or not.

It seems you're currently "testing" in quirks mode. I suggest we only look  
at standards mode as that's relevant for the HTML5 parsing section.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From lachlan.hunt at lachy.id.au  Sun Sep 10 06:40:24 2006
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Sun, 10 Sep 2006 23:40:24 +1000
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <Pine.LNX.4.64.0609101241030.5348@holly>
References: <Pine.LNX.4.64.0609081735250.5305@holly>	<op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>	<Pine.LNX.4.64.0609101045340.5363@holly>
	<4503ED53.4070304@lachy.id.au>
	<Pine.LNX.4.64.0609101241030.5348@holly>
Message-ID: <450415C8.5070806@lachy.id.au>

Dave Raggett wrote:
> You can reproduce my tests by pointing your browser at:
> 
>   http://people.w3.org/~dsr/dom/test.html

OK, I have the discovered the reason for the discrepancy in our results. 
  Apparently IE handles exactly the same markup differently depending 
upon how it is added to the page.

If you load my test case [1] in IE, tests A through E are styled, but 
test F isn't.  This shows the following:

IE will only allow styling of elements with namespace prefixes that have 
been either explicitly or implicitly declared.

There are two ways to explicitly declare a namespace in IE:
1. <html xmlns:foo="http://example.org/foo">
2. <?xml:namespace prefix = foo ns = "http://example.org/foo" />

In both cases, the URI may be omitted.

When a "Custom Tag" (the name Microsoft have given elements with 
namespace prefixes in HTML) is added using either innerHTML or 
document.write(), the PI that declares the namespace will be implicitly 
generated using the prefix but with no actual namespace name.

This explains why I was getting different results using the Live DOM 
Viewer because it uses innerHTML to copy the markup from the text box to 
the rendering area.  That means that IE was implicitly declaring the 
namespace of all Custom Tags in my tests.

[1] http://lachy.id.au/dev/2006/09/custom-tags

-- 
Lachlan Hunt
http://lachy.id.au/


From dsr at w3.org  Sun Sep 10 09:29:02 2006
From: dsr at w3.org (Dave Raggett)
Date: Sun, 10 Sep 2006 17:29:02 +0100 (BST)
Subject: [whatwg] Hacking away on forms ... (fwd)
In-Reply-To: <op.tfnw6zpwaw9dld@id-c0020.oslo.opera.com>
References: <Pine.LNX.4.64.0609081735250.5305@holly>
	<op.tfmb2p0raw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.64.0609101045340.5363@holly> <4503ED53.4070304@lachy.id.au>
	<Pine.LNX.4.64.0609101241030.5348@holly>
	<op.tfnw6zpwaw9dld@id-c0020.oslo.opera.com>
Message-ID: <Pine.LNX.4.64.0609101725310.5348@holly>

On Sun, 10 Sep 2006, Anne van Kesteren wrote:

> On Sun, 10 Sep 2006 14:19:02 +0200, Dave Raggett <dsr at w3.org> wrote:
>> You can then use view source to look at the source markup. Let me 
>> know if you want to create some more tests. For example, it's 
>> possible that the results will vary according to whether IE is in 
>> quirks mode or not.
>
> It seems you're currently "testing" in quirks mode. I suggest we 
> only look at standards mode as that's relevant for the HTML5 
> parsing section.

Well I tried removing the XML declaration and adding the doctype
for XHTML, but it doesn't seem to have made any difference.

  http://people.w3.org/~dsr/dom/test2.html

p.s. I was using the info on quirks mode at:

           http://en.wikipedia.org/wiki/Quirks_mode

  Dave Raggett <dsr at w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)



From fora at annevankesteren.nl  Sun Sep 10 09:49:52 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Sun, 10 Sep 2006 18:49:52 +0200
Subject: [whatwg] Editorial: parsing section
Message-ID: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>

When you have phrases like 'Change the insertion mode to "in select".' it
would be nice if "in select" was a pointer to the relevant section.
Currently "insertion mode" is a pointer and that's hardly useful.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From fora at annevankesteren.nl  Tue Sep 12 01:06:20 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Tue, 12 Sep 2006 10:06:20 +0200
Subject: [whatwg] Fwd: Re: [xhtml-role] Extensibility of XHTML 1 and XHTML
	1.1 (PR#9627)
In-Reply-To: <200609120801.k8C81Pm1023273@htmlwg.mn.aptest.com>
References: <200609120801.k8C81Pm1023273@htmlwg.mn.aptest.com>
Message-ID: <op.tfq94ur2aw9dld@id-c0020.oslo.opera.com>

Might be of interest...


------- Forwarded message -------
From: "Shane McCarron" <voyager-issues at mn.aptest.com>
To: karl at w3.org
Cc: www-html-editor at w3.org
Subject: Re: [xhtml-role] Extensibility of XHTML 1 and XHTML 1.1 (PR#9627)
Date: Tue, 12 Sep 2006 10:01:25 +0200


XHTML2 will be using the same namespace as XHTML1, and there will not be
two
modules.



-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From lachlan.hunt at lachy.id.au  Tue Sep 12 04:29:50 2006
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Tue, 12 Sep 2006 21:29:50 +1000
Subject: [whatwg] Fwd: Re: [xhtml-role] Extensibility of XHTML 1 and
 XHTML 1.1 (PR#9627)
In-Reply-To: <op.tfq94ur2aw9dld@id-c0020.oslo.opera.com>
References: <200609120801.k8C81Pm1023273@htmlwg.mn.aptest.com>
	<op.tfq94ur2aw9dld@id-c0020.oslo.opera.com>
Message-ID: <45069A2E.9060008@lachy.id.au>

Anne van Kesteren forwarded this from Shane McCarron:
> XHTML2 will be using the same namespace as XHTML1, and there will not be
> two modules.

Great news!  I wonder how open the HTML WG will be with regards to 
working with the WHATWG and HTML 5, especially now that the 2 specs will 
share the same namespace.  If we don't resolve the incompatibilities, 
one of the specs will simply be doomed to failure.

-- 
Lachlan Hunt
http://lachy.id.au/


From ian at hixie.ch  Tue Sep 12 06:51:53 2006
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 Sep 2006 06:51:53 -0700
Subject: [whatwg] Fwd: Re: [xhtml-role] Extensibility of XHTML 1 and
	XHTML 1.1 (PR#9627)
In-Reply-To: <45069A2E.9060008@lachy.id.au>
References: <200609120801.k8C81Pm1023273@htmlwg.mn.aptest.com>
	<op.tfq94ur2aw9dld@id-c0020.oslo.opera.com>
	<45069A2E.9060008@lachy.id.au>
Message-ID: <403d38e20609120651p6bad3ecbqa333bad833738f1a@mail.gmail.com>

Anne van Kesteren forwarded this from Shane McCarron:
> XHTML2 will be using the same namespace as XHTML1, and there will not be
> two modules.

This has been an "issue" in the XHTML2 draft for some time:
http://www.w3.org/TR/xhtml2/conformance.html#s_conform_issue_4


On 9/12/06, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> Great news!  I wonder how open the HTML WG will be with regards to
> working with the WHATWG and HTML 5, especially now that the 2 specs will
> share the same namespace.  If we don't resolve the incompatibilities,
> one of the specs will simply be doomed to failure.

I would be more concerned about how they are intending on making
XHTML2 compatible with XHTML1 than with the WHATWG work. For example,
XHTML2's <input> element has basically completely different semantics
than XHTML1's. Even simple elements like <img> and <q> are
incompatible across the two versions, in the current draft.

-- 
Ian Hickson


From mattraymond at earthlink.net  Tue Sep 12 08:14:26 2006
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Tue, 12 Sep 2006 11:14:26 -0400
Subject: [whatwg] Fwd: Re: [xhtml-role] Extensibility of XHTML 1
 and	XHTML 1.1 (PR#9627)
In-Reply-To: <403d38e20609120651p6bad3ecbqa333bad833738f1a@mail.gmail.com>
References: <200609120801.k8C81Pm1023273@htmlwg.mn.aptest.com>	<op.tfq94ur2aw9dld@id-c0020.oslo.opera.com>	<45069A2E.9060008@lachy.id.au>
	<403d38e20609120651p6bad3ecbqa333bad833738f1a@mail.gmail.com>
Message-ID: <4506CED2.7040202@earthlink.net>

Ian Hickson wrote:
> I would be more concerned about how they are intending on making
> XHTML2 compatible with XHTML1 than with the WHATWG work.

   Hopefully they won't revive the |version| attribute, as John M. Boyer
has suggested.

> For example,
> XHTML2's <input> element has basically completely different semantics
> than XHTML1's.

   That's because XHTML 2.0 simply reuses XForms in the XHTML namespace,
so the HTML WG isn't the place to debate this, unfortunately. You really
need to catch up on the public-appformats mailing list when you have the
opportunity. There's lively debate about <input>, XForms and WF2 there.
(Should we be CCing those messages to this mailing list?)

> Even simple elements like <img> and <q> are
> incompatible across the two versions, in the current draft.

http://www.w3.org/TR/xhtml2/mod-image.html#edef_image_img

| The img element is a holder for embedding attributes such as src.
| Since these attributes may be applied to any element, the img element
| is not strictly necessary, but is included to ease the transition to
| XHTML2.

   Why are they even including it then, especially since <object> has
the same content model and supports images?


http://www.w3.org/TR/xhtml2/mod-text.html#edef_text_q

| Visual user agents must not by default add delimiting quotation marks
| (as was the case for the q element in earlier versions of XHTML and
| HTML). It is the responsibility of the document author to add any
| required quotation marks, either directly in the text, or via a style
| sheet.

   So what's the use of <q> in XHTML 2.0? If there's no difference
between the default styling and standard text, what's the web author's
motivation to use it?

   Furthermore, putting quotation characters in the markup is useless if
you want to quote a quote. In HTML and XHTML 1.x, you could simply nest
<q> elements, but that's not the case with XHTML 2.0.

   Also, why get rid of <acronym>? It's more widely supported than
<abbr>. Granted, it's sort of a subset of <abbr>, but acronyms are
common enough to justify their own element.

   The <l> and <br> elements might be able to coexist, so long as we
specify them correctly. For instance, <l> should never contain a <br>.
Would <l> be styled as block, though, rather than inline? What happens
if it runs over?

   Well, enough for now...


From ian at hixie.ch  Tue Sep 12 08:18:27 2006
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 Sep 2006 08:18:27 -0700
Subject: [whatwg] Fwd: Re: [xhtml-role] Extensibility of XHTML 1 and
	XHTML 1.1 (PR#9627)
In-Reply-To: <4506CED2.7040202@earthlink.net>
References: <200609120801.k8C81Pm1023273@htmlwg.mn.aptest.com>
	<op.tfq94ur2aw9dld@id-c0020.oslo.opera.com>
	<45069A2E.9060008@lachy.id.au>
	<403d38e20609120651p6bad3ecbqa333bad833738f1a@mail.gmail.com>
	<4506CED2.7040202@earthlink.net>
Message-ID: <403d38e20609120818g1d325bf0oda09f7b52f60aa9b@mail.gmail.com>

On 9/12/06, Matthew Raymond <mattraymond at earthlink.net> wrote:
> >
> > For example,
> > XHTML2's <input> element has basically completely different semantics
> > than XHTML1's.
>
> That's because XHTML 2.0 simply reuses XForms in the XHTML namespace,
> so the HTML WG isn't the place to debate this, unfortunately.

Yeah.

WHATWG isn't really the place to debate this either, I guess. Let's
leave this problem up to the W3C to deal with.

(PS. Just one more week of vacation and then I'll be resuming work on
WA1. Hopefully we can get this baby into a feature-complete state
soon.)

-- 
Ian Hickson


From fora at annevankesteren.nl  Tue Sep 12 08:37:17 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Tue, 12 Sep 2006 17:37:17 +0200
Subject: [whatwg] <acronym> (was: Re: Fwd: Re: [xhtml-role] Extensibility of
	XHTML 1 and XHTML 1.1 (PR#9627))
In-Reply-To: <4506CED2.7040202@earthlink.net>
References: <200609120801.k8C81Pm1023273@htmlwg.mn.aptest.com>
	<op.tfq94ur2aw9dld@id-c0020.oslo.opera.com>
	<45069A2E.9060008@lachy.id.au>
	<403d38e20609120651p6bad3ecbqa333bad833738f1a@mail.gmail.com>
	<4506CED2.7040202@earthlink.net>
Message-ID: <op.tfru0fxaaw9dld@id-c0020.oslo.opera.com>

On Tue, 12 Sep 2006 17:14:26 +0200, Matthew Raymond  
<mattraymond at earthlink.net> wrote:
>    Also, why get rid of <acronym>? It's more widely supported than
> <abbr>. Granted, it's sort of a subset of <abbr>, but acronyms are
> common enough to justify their own element.

Actually, I agree with dropping <acronym>. It's just there to confuse  
authors. (HTML5 doesn't include it either.)


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From fora at annevankesteren.nl  Tue Sep 12 08:44:27 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Tue, 12 Sep 2006 17:44:27 +0200
Subject: [whatwg] Fwd: Re: [xhtml-role] Extensibility of XHTML 1 and
	XHTML 1.1 (PR#9627)
In-Reply-To: <403d38e20609120651p6bad3ecbqa333bad833738f1a@mail.gmail.com>
References: <200609120801.k8C81Pm1023273@htmlwg.mn.aptest.com>
	<op.tfq94ur2aw9dld@id-c0020.oslo.opera.com>
	<45069A2E.9060008@lachy.id.au>
	<403d38e20609120651p6bad3ecbqa333bad833738f1a@mail.gmail.com>
Message-ID: <op.tfrvcdd6aw9dld@id-c0020.oslo.opera.com>

On Tue, 12 Sep 2006 15:51:53 +0200, Ian Hickson <ian at hixie.ch> wrote:
> Anne van Kesteren forwarded this from Shane McCarron:
>> XHTML2 will be using the same namespace as XHTML1, and there will not be
>> two modules.
>
> This has been an "issue" in the XHTML2 draft for some time:
> http://www.w3.org/TR/xhtml2/conformance.html#s_conform_issue_4

Yeah, I noticed that. I just thought that was there to please someone as  
it doesn't really seem like an option, as you point in your reply to  
Lachlan... Oh well, should be fun!


> I would be more concerned about how they are intending on making
> XHTML2 compatible with XHTML1 than with the WHATWG work. For example,
> XHTML2's <input> element has basically completely different semantics
> than XHTML1's. Even simple elements like <img> and <q> are
> incompatible across the two versions, in the current draft.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From joao.eiras at gmail.com  Tue Sep 19 16:27:12 2006
From: joao.eiras at gmail.com (Joao Eiras)
Date: Wed, 20 Sep 2006 00:27:12 +0100
Subject: [whatwg] MediaModeAbstractView and changing of media dynamically
Message-ID: <op.tf5ffmvzxl3at9@dragast.mshome.net>

For me, the w3c DOM 2 stylesheets spec always had the gap, which  
MediaModeAbstractView fixes: a variable which holds the current media how  
the page is being rendered.
But there's another small gap. Some UAs (Opera for desktop only to my  
knowledge) can change the current media by displaying a webpage as  
fullscreen (projection) or enabling small screen rendering (handheld). I  
assume future versions will allow Opera to trigger tv mode, for  
development sake. Also any other browsers can change from normal rendering  
(screen) to print preview (print).

The only way for a script to keep track of this variable value, is to set  
an interval, polling the variable.
I don't consider refreshing the page as valid workaround.

So, I suggest the creation of the 'media-change' event, which will fire  
when the UA changes media, having the document as target.
The event object could be an instance of a UIEvent, and have 2 extra  
properties: newMediaMode, and oldMediaMode.


From ian at hixie.ch  Tue Sep 19 16:39:30 2006
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 19 Sep 2006 23:39:30 +0000 (UTC)
Subject: [whatwg] Enhanced data tables
In-Reply-To: <E80F2D4C-45CB-11D9-85F5-000A95AD3972@myrealbox.com>
References: <C5613EDC-30EB-11D9-9F1E-000A957E8988@uk2.net>
	<0BF1DCCA-3135-11D9-ABBD-000A95AD3972@myrealbox.com>
	<Pine.LNX.4.61.0412031701020.20176@dhalsim.dreamhost.com>
	<569C3FA2-4551-11D9-807B-000A957E8988@uk2.net>
	<E80F2D4C-45CB-11D9-85F5-000A95AD3972@myrealbox.com>
Message-ID: <Pine.LNX.4.62.0609192333150.21538@dhalsim.dreamhost.com>

On Sat, 4 Dec 2004, Matthew Thomas wrote:
> On 4 Dec, 2004, at 6:32 AM, Afternoon wrote:
> > On 3 Dec 2004, at 17:18, Ian Hickson wrote:
> > ...
> > > From a practical standpoint the difference between a <table> and a data
> > > grid is that the table's data is all in a DOM content model, whereas the
> > > data grid can be dynamically populated from script, one row at a time, so
> > > that only the displayed portion need be in memory at any one time.
> 
> Could functions be devised to make populating (and depopulating) <table> 
> rows and columns easier than it is now, without inventing a new element 
> for such tables?

Not without further overloading the <table> element. The requirements for 
implementing <table> are already pretty onerous, with custom DOM 
interfaces, at least three rendering models, one of which is not formally 
defined anywhere, the second of which is only poorly defined, peculiar 
parsing requirements, etc.

By having a new element, which can wrap <table>, we can reuse the <table> 
semantics, while still allowing UAs to separate their <table> 
implementation from the new code neatly.

<table> is a very brittle element in terms of implementations -- it's a 
source of many quite complex bugs. Adding more complex code to <table> 
doesn't seem like a good idea.


> > > Another difference is that tables have a legacy of rendering 
> > > semantics which we can't do much about, whereas for the data grid we 
> > > want to be able to use GUI-specific native controls (or 
> > > native-looking controls) which have features such as clickable 
> > > column headers, draggable column separators, etc. Also, datagrids 
> > > are limited to text in each cell (with one icon per row), rows can 
> > > be selected, data can be marked as editable, etc.
> >
> > Indeed, a browser that assumed every <table> was data-bearing and 
> > should have controls displayed would be all but useless.
> 
> That's why I suggested those controls be displayed only for <th> 
> elements, not for every <table>.

I'm not convinced that this would be enough to avoid breaking assumptions 
made by existing Web pages. It also would, as mentioned above, require 
overloading of <table>.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Sep 19 16:45:44 2006
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 19 Sep 2006 23:45:44 +0000 (UTC)
Subject: [whatwg] Web Apps 1.0 - DataGrid
In-Reply-To: <42A9EC1C.7010106@coralbark.net>
References: <42A9EC1C.7010106@coralbark.net>
Message-ID: <Pine.LNX.4.62.0609192340110.21538@dhalsim.dreamhost.com>

On Fri, 10 Jun 2005, Jon Levell wrote:
> 
> I'm currently struggling to write a web application for the company 
> where I work and I'm hoping you guys could make it easier for future 
> versions of me.
> 
> What I'm trying to do is have a large table of information where the row 
> and column headers are fixed but the contents scroll. It is possible in 
> JavaScript at the moment. For a good example (not written by me) see: 
> http://www.litotes.demon.co.uk/example_scripts/tableScroll.html

This is more of a rendering issue than a markup issue -- it's probably 
something the CSS working group should look at more closely. (We've looked 
at it before, but never for very long.)

Thanks for the feedback, though, I'll make sure to bring this up with the 
CSS WG again.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ajvincent at gmail.com  Wed Sep 20 01:05:55 2006
From: ajvincent at gmail.com (Alex Vincent)
Date: Wed, 20 Sep 2006 01:05:55 -0700
Subject: [whatwg] WF2: Clarification on valueMissing requested
Message-ID: <9301ed6b0609200105l555f6fbbu48da0dfd17a0c349@mail.gmail.com>

"The field has the required  attribute set but has no value selected."

In implementing this for Mozilla, I realized an edge case that could
prove troublesome.  Specifically, what happens if you have multiple
radio or checkboxes with the required attribute and no boxes checked
for any of them.

Alternatively, consider when the radio button is checked but doesn't
have a value... and some other radio input with the same name in the
same form does have a value.

There's an attempt to clarify it here:

"When a radio group has no checked radio button and more than one of
the radio buttons is marked as required, the UA should only tell the
user that the radio group as a whole is missing a value, not complain
about each radio button in turn, even though all of the radio buttons
marked with the required attribute would have the valueMissing flag
set."

Tell the user how?  Visually?  Through DOM events?  Both, or some
other way?  I'm working from the DOM events view right now, and this
could be the difference between dispatching one event and dispatching
many.

I don't require an immediate answer.  Forgive me if the questions
above have already been raised and discussed.

Alex Vincent

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001


From fora at annevankesteren.nl  Wed Sep 20 04:26:35 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Wed, 20 Sep 2006 11:26:35 -0000
Subject: [whatwg] MediaModeAbstractView and changing of media dynamically
In-Reply-To: <op.tf5ffmvzxl3at9@dragast.mshome.net>
References: <op.tf5ffmvzxl3at9@dragast.mshome.net>
Message-ID: <op.tf6cqlzvaw9dld@id-c0020.emi.ac.ma>

On Tue, 19 Sep 2006 23:27:12 -0000, Joao Eiras <joao.eiras at gmail.com>  
wrote:
> So, I suggest the creation of the 'media-change' event, which will fire  
> when the UA changes media, having the document as target.
> The event object could be an instance of a UIEvent, and have 2 extra  
> properties: newMediaMode, and oldMediaMode.

This has already been suggested multiple times on this list. Personally, I  
think a better place is probably the new CSSOM (whenever I get around to  
it...).


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From hallvors at gmail.com  Wed Sep 20 07:26:00 2006
From: hallvors at gmail.com (Hallvord R M Steen)
Date: Wed, 20 Sep 2006 16:26:00 +0200
Subject: [whatwg] scripts that remove focus from links during document
	navigation
Message-ID: <dd4c8a40609200726r6ecbc518i7ce91bbef0495016@mail.gmail.com>

( Previously sent to public-webapi at w3.org list but Anne v K agrees it
probably belongs here.. )

Opera has a serious usability problem for keyboard- and device-users when
pages do the following:

<a href="" onfocus="this.blur()">

This coding is very common because IE adds a small outline border to
focused links. Authors who do not like this will blur links when they are
activated to avoid this cosmetic issue. (Mea culpa: I've done exactly this
myself in sites I coded as a newbie, for that very reason.)

In Opera, when keyboard navigation hits this link, focus is removed. Thus
the link can not be activated from the keyboard and navigation may have to
start from the top of the document again.

We need some prose in a spec that allows a user agent to ignore blur() for
accessibility reasons. This text has been suggested by Fabian Valkenburg:

'scripts must not alter focus-related issues in a way that hinder keyboard
operation, and user agents may override any such use of focus-related
scripting operations.'

I'm not sure what spec to put it in, and we've also discussed possible
collateral damage if sites use this in legitimate ways. Thoughts?


-- 
Hallvord R. M. Steen


From lachlan.hunt at lachy.id.au  Wed Sep 20 09:17:30 2006
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Thu, 21 Sep 2006 02:17:30 +1000
Subject: [whatwg] scripts that remove focus from links during document
 navigation
In-Reply-To: <dd4c8a40609200726r6ecbc518i7ce91bbef0495016@mail.gmail.com>
References: <dd4c8a40609200726r6ecbc518i7ce91bbef0495016@mail.gmail.com>
Message-ID: <4511699A.7070306@lachy.id.au>

Hallvord R M Steen wrote:
> Opera has a serious usability problem for keyboard- and device-users when
> pages do the following:
> 
> <a href="" onfocus="this.blur()">
> 
> We need some prose in a spec that allows a user agent to ignore blur() for
> accessibility reasons...
> 
> I'm not sure what spec to put it in, and we've also discussed possible
> collateral damage if sites use this in legitimate ways. Thoughts?

What legitimate use cases are there for blur()?  I've never used it, 
I've never never seen it used in a way that hasn't forced me to disable 
script to workaround it, and my searches only found explanations of how 
to use it, not why or when to use it.

-- 
Lachlan Hunt
http://lachy.id.au/


From jim.ley at gmail.com  Wed Sep 20 14:07:25 2006
From: jim.ley at gmail.com (Jim Ley)
Date: Wed, 20 Sep 2006 22:07:25 +0100
Subject: [whatwg] scripts that remove focus from links during document
	navigation
In-Reply-To: <dd4c8a40609200726r6ecbc518i7ce91bbef0495016@mail.gmail.com>
References: <dd4c8a40609200726r6ecbc518i7ce91bbef0495016@mail.gmail.com>
Message-ID: <851c8d310609201407m7486b14cr9150095cbf050855@mail.gmail.com>

On 20/09/06, Hallvord R M Steen <hallvors at gmail.com> wrote:
> <a href="" onfocus="this.blur()">
>
> This coding is very common because IE adds a small outline border to
> focused links. Authors who do not like this will blur links when they are
> activated to avoid this cosmetic issue. (Mea culpa: I've done exactly this
> myself in sites I coded as a newbie, for that very reason.)

The reason being you'd not heard of the hidefocus attribute :-)  or
onfocus="this.hideFocus=true" if you want to be free.

> In Opera, when keyboard navigation hits this link, focus is removed. Thus
> the link can not be activated from the keyboard and navigation may have to
> start from the top of the document again.

Right so ignore it.

> We need some prose in a spec that allows a user agent to ignore blur() for
> accessibility reasons.

Why do you?  there's no prose in any spec which says you have to
support any script etc., and if there is, I would encourage you to
break it anyway, obviously anything that harms accessibility to your
users is something that it is your duty as a web-browser company to
not do.

I can appreciate you'd rather point to some other place and go "look,
look they said it was okay", but in that case you already have it UAAG
is fine for that.  I don't think it's good to spell out and make
specifications even longer just to give you somewhere to point pretty
deluded authors.

> 'scripts must not alter focus-related issues in a way that hinder keyboard
> operation, and user agents may override any such use of focus-related
> scripting operations.'

I don't like this, it doesn't define hinder well enough for a MUST,
can't you just take it as read that you're allowed to?

I can't foresee any realistic collateral damage from actually blocking
the behaviour - but if that genuinely is the case, then removing blur
entirely would be a more appropriate solution.

Mostly though I encourage you to continue in the vein of promoting
your user, rather than hiding behind spec's, you've done it so well to
date!

Jim.


From ian at hixie.ch  Thu Sep 21 12:29:41 2006
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 21 Sep 2006 19:29:41 +0000 (UTC)
Subject: [whatwg] Server-sent events or Server-sent DOM events?
In-Reply-To: <165276294.20060902104913@gmx.net>
References: <165276294.20060902104913@gmx.net>
Message-ID: <Pine.LNX.4.62.0609211928570.21538@dhalsim.dreamhost.com>

On Sat, 2 Sep 2006 akusaya at gmx.net wrote:
>
> Or is Server-sent DOM events a more specific name for Server-sent 
> events?

Server-sent DOM events is a more specific name.

I don't really like either name, if you have a better suggestion that 
would be fine too. You could also refer to the feature as "the 
event-source element" or something like that.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Sep 21 12:40:18 2006
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 21 Sep 2006 19:40:18 +0000 (UTC)
Subject: [whatwg] Editorial: parsing section
In-Reply-To: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>
References: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>
Message-ID: <Pine.LNX.4.62.0609211934140.21538@dhalsim.dreamhost.com>

On Sun, 10 Sep 2006, Anne van Kesteren wrote:
>
> When you have phrases like 'Change the insertion mode to "in select".' 
> it would be nice if "in select" was a pointer to the relevant section. 
> Currently "insertion mode" is a pointer and that's hardly useful.

The problem is the "in select" mode includes the start of the "in body" 
mode. e.g. whatever insertion mode you're in, if you find a <!DOCTYPE>, 
you have to handle it as described at the top of 8.2.4.3.7. But I suppose 
we could add the links anyway... What do you think? Do you really want the 
links, even though they'd be kind of technically incorrect?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From codedread at gmail.com  Fri Sep 22 14:04:27 2006
From: codedread at gmail.com (Jeff Schiller)
Date: Fri, 22 Sep 2006 16:04:27 -0500
Subject: [whatwg] Help with HTML5 Audio
Message-ID: <da131fde0609221404n1e1da1a9gc168015a1b3f16c0@mail.gmail.com>

Opera 9 implements the Audio interface proposed in HTML5:
http://whatwg.org/specs/web-apps/current-work/#scs-sound

I'm having trouble with it. My first attempt was:

var soundClip = new Audio("blah.wav");
if(soundClip) { soundClip.play(); }

This doesn't work on the first attempt, but on the second attempt it
plays the sound just fine. The only thing I could deduce was that the
first execution, the .play() lines was happening before the .wav file
finished loading from the server. But once the file is loaded from the
web server, subsequent invocations of this script mean the file has
cached, so the second line is happening after the load event.

Sure enough, the HTML5 spec talks about the "Audio object that will,
at the completion of the current script, start loading that URI" and
"Once the URI is loaded, a load event must be fired on the Audio
object"

So this was my second attempt:

function playSound(evt) {
if(evt && evt.target && evt.target.play) { evt.target.play(); }
}
...
var soundClip = new Audio("blah.wav");
if(soundClip) { soundClip.addEventListener("load", playSound, true); }

However, this doesn't seem to work at all (no matter how many times I
call it). So I'm not sure what I'm doing wrong. Is it possible that
I'm trying to add the event listener after the sound loads (in which
case the Load event already fires)? If so, how can I get around this?

I need a solution that will work whether the sound is cached or not.
Is this a problem in the spec or a problem with my understanding of
this object or event handlers?

Thanks,
Jeff


From codedread at gmail.com  Sat Sep 23 15:39:45 2006
From: codedread at gmail.com (Jeff Schiller)
Date: Sat, 23 Sep 2006 17:39:45 -0500
Subject: [whatwg] Help with HTML5 Audio
In-Reply-To: <da131fde0609221404n1e1da1a9gc168015a1b3f16c0@mail.gmail.com>
References: <da131fde0609221404n1e1da1a9gc168015a1b3f16c0@mail.gmail.com>
Message-ID: <da131fde0609231539n763fc622w1b00c0d0483d2d38@mail.gmail.com>

Thanks for all the replies off the mailing list...

This my just be an education problem.  Let me ask a few questions:

Do load events bubble up?  If so, can I add a load even listener to
the document and then catch the load events there always?

If so, how can I distinguish the target is of type Audio and not of
type HTMLImageElement (or whatever), just look for e.target.play?

If my understanding is not correct above (and I will test this later),
then it seems that the spec gives me no way to guarantee that I can
attach a load event listener to the Audio object prior to the song
loading (especially for cached sounds).

Although this doesn't help me for Opera 9, I would like to propose
that the Audio constructor's argument be OPTIONAL.  If there is no
argument, then the Audio object is created without any sound loaded
and all play(), loop(), etc would just return (or return an error or
throw an exception?).  Then, add a load() method to the interface
(which would produce a load event just as the construction with an
argument would).  This also allows me to reuse the Audio object
instead of creating an Audio object for each different sound...

Thanks,
Jeff


On 9/22/06, Jeff Schiller <codedread at gmail.com> wrote:
> Opera 9 implements the Audio interface proposed in HTML5:
> http://whatwg.org/specs/web-apps/current-work/#scs-sound
>
> I'm having trouble with it. My first attempt was:
>
> var soundClip = new Audio("blah.wav");
> if(soundClip) { soundClip.play(); }
>
> This doesn't work on the first attempt, but on the second attempt it
> plays the sound just fine. The only thing I could deduce was that the
> first execution, the .play() lines was happening before the .wav file
> finished loading from the server. But once the file is loaded from the
> web server, subsequent invocations of this script mean the file has
> cached, so the second line is happening after the load event.
>
> Sure enough, the HTML5 spec talks about the "Audio object that will,
> at the completion of the current script, start loading that URI" and
> "Once the URI is loaded, a load event must be fired on the Audio
> object"
>
> So this was my second attempt:
>
> function playSound(evt) {
> if(evt && evt.target && evt.target.play) { evt.target.play(); }
> }
> ...
> var soundClip = new Audio("blah.wav");
> if(soundClip) { soundClip.addEventListener("load", playSound, true); }
>
> However, this doesn't seem to work at all (no matter how many times I
> call it). So I'm not sure what I'm doing wrong. Is it possible that
> I'm trying to add the event listener after the sound loads (in which
> case the Load event already fires)? If so, how can I get around this?
>
> I need a solution that will work whether the sound is cached or not.
> Is this a problem in the spec or a problem with my understanding of
> this object or event handlers?
>
> Thanks,
> Jeff
>


From fora at annevankesteren.nl  Sun Sep 24 08:30:23 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Sun, 24 Sep 2006 17:30:23 +0200
Subject: [whatwg] Editorial: parsing section
In-Reply-To: <Pine.LNX.4.62.0609211934140.21538@dhalsim.dreamhost.com>
References: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.62.0609211934140.21538@dhalsim.dreamhost.com>
Message-ID: <op.tgdi9jqraw9dld@localhost>

On Thu, 21 Sep 2006 19:40:18 -0000, Ian Hickson <ian at hixie.ch> wrote:
>> When you have phrases like 'Change the insertion mode to "in select".'
>> it would be nice if "in select" was a pointer to the relevant section.
>> Currently "insertion mode" is a pointer and that's hardly useful.
>
> The problem is the "in select" mode includes the start of the "in body"
> mode. e.g. whatever insertion mode you're in, if you find a <!DOCTYPE>,
> you have to handle it as described at the top of 8.2.4.3.7. But I suppose
> we could add the links anyway... What do you think? Do you really want  
> the links, even though they'd be kind of technically incorrect?

The "in select" mode seems to assert something else than what you say,  
actually. It handles all cases itself already... Including "anything else".


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From ian at hixie.ch  Sun Sep 24 18:46:56 2006
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 25 Sep 2006 01:46:56 +0000 (UTC)
Subject: [whatwg] Editorial: parsing section
In-Reply-To: <op.tgdi9jqraw9dld@localhost>
References: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.62.0609211934140.21538@dhalsim.dreamhost.com>
	<op.tgdi9jqraw9dld@localhost>
Message-ID: <Pine.LNX.4.62.0609250145330.13053@dhalsim.dreamhost.com>

On Sun, 24 Sep 2006, Anne van Kesteren wrote:
>
> On Thu, 21 Sep 2006 19:40:18 -0000, Ian Hickson <ian at hixie.ch> wrote:
> > > When you have phrases like 'Change the insertion mode to "in 
> > > select".' it would be nice if "in select" was a pointer to the 
> > > relevant section. Currently "insertion mode" is a pointer and that's 
> > > hardly useful.
> > 
> > The problem is the "in select" mode includes the start of the "in 
> > body" mode. e.g. whatever insertion mode you're in, if you find a 
> > <!DOCTYPE>, you have to handle it as described at the top of 
> > 8.2.4.3.7. But I suppose we could add the links anyway... What do you 
> > think? Do you really want the links, even though they'd be kind of 
> > technically incorrect?
> 
> The "in select" mode seems to assert something else than what you say, 
> actually. It handles all cases itself already... Including "anything 
> else".

Your confusion here is exactly what I'm worried about. The point is that 
in the main phase, whatever the insertion mode, you have to start each 
token's processing from the start of the main phase. Which handles the 
DOCTYPEs and certain character nodes, before looking at the insertion mode 
flag and handling the other things (including "anything else").

Insertion modes are not phases. They are all processed as part of the main 
phase process each time.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From fora at annevankesteren.nl  Mon Sep 25 03:26:20 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Mon, 25 Sep 2006 12:26:20 +0200
Subject: [whatwg] Editorial: parsing section
In-Reply-To: <Pine.LNX.4.62.0609250145330.13053@dhalsim.dreamhost.com>
References: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.62.0609211934140.21538@dhalsim.dreamhost.com>
	<op.tgdi9jqraw9dld@localhost>
	<Pine.LNX.4.62.0609250145330.13053@dhalsim.dreamhost.com>
Message-ID: <op.tgfi961raw9dld@id-c0020.oslo.opera.com>

On Mon, 25 Sep 2006 03:46:56 +0200, Ian Hickson <ian at hixie.ch> wrote:
> Your confusion here is exactly what I'm worried about. The point is that
> in the main phase, whatever the insertion mode, you have to start each
> token's processing from the start of the main phase. Which handles the
> DOCTYPEs and certain character nodes, before looking at the insertion  
> mode flag and handling the other things (including "anything else").
>
> Insertion modes are not phases. They are all processed as part of the  
> main phase process each time.

Ah, I understand what you mean now (I think). Currently I only see DOCTYPE  
and "html" start tag there. Shouldn't Comment be there as well?

Anyway, perhaps you should have a note somewhere to make this more clear?


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From ian at hixie.ch  Mon Sep 25 10:01:34 2006
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 25 Sep 2006 17:01:34 +0000 (UTC)
Subject: [whatwg] Editorial: parsing section
In-Reply-To: <op.tgfi961raw9dld@id-c0020.oslo.opera.com>
References: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.62.0609211934140.21538@dhalsim.dreamhost.com>
	<op.tgdi9jqraw9dld@localhost>
	<Pine.LNX.4.62.0609250145330.13053@dhalsim.dreamhost.com>
	<op.tgfi961raw9dld@id-c0020.oslo.opera.com>
Message-ID: <Pine.LNX.4.62.0609251700340.13053@dhalsim.dreamhost.com>

On Mon, 25 Sep 2006, Anne van Kesteren wrote:
>
> On Mon, 25 Sep 2006 03:46:56 +0200, Ian Hickson <ian at hixie.ch> wrote:
> > Your confusion here is exactly what I'm worried about. The point is that
> > in the main phase, whatever the insertion mode, you have to start each
> > token's processing from the start of the main phase. Which handles the
> > DOCTYPEs and certain character nodes, before looking at the insertion mode
> > flag and handling the other things (including "anything else").
> > 
> > Insertion modes are not phases. They are all processed as part of the main
> > phase process each time.
> 
> Ah, I understand what you mean now (I think). Currently I only see DOCTYPE and
> "html" start tag there. Shouldn't Comment be there as well?

Comments are handled differently in "after body" mode than in the other 
modes.


> Anyway, perhaps you should have a note somewhere to make this more clear?

I'm not sure what the note would be and where it should go... can you 
suggest some text and a location? I'd love to make this clearer but I'm 
probably too close to it to understand how to do so.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From fora at annevankesteren.nl  Mon Sep 25 10:14:05 2006
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Mon, 25 Sep 2006 19:14:05 +0200
Subject: [whatwg] Editorial: parsing section
In-Reply-To: <Pine.LNX.4.62.0609251700340.13053@dhalsim.dreamhost.com>
References: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.62.0609211934140.21538@dhalsim.dreamhost.com>
	<op.tgdi9jqraw9dld@localhost>
	<Pine.LNX.4.62.0609250145330.13053@dhalsim.dreamhost.com>
	<op.tgfi961raw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.62.0609251700340.13053@dhalsim.dreamhost.com>
Message-ID: <op.tgf15rmfaw9dld@id-c0020.oslo.opera.com>

On Mon, 25 Sep 2006 19:01:34 +0200, Ian Hickson <ian at hixie.ch> wrote:
>> Anyway, perhaps you should have a note somewhere to make this more  
>> clear?
>
> I'm not sure what the note would be and where it should go... can you
> suggest some text and a location? I'd love to make this clearer but I'm
> probably too close to it to understand how to do so.

After the first paragraph of section 8.2.4.3.6. you could have something  
like:

   Besides everything noted in the specific insertion mode
   covered by "Anything else" in "How to handle tokens in
   the main phase" the other items in that section are to
   considered as well when handling the specific insertion
   mode, such as a DOCTYPE token.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From ian at hixie.ch  Mon Sep 25 10:34:37 2006
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 25 Sep 2006 17:34:37 +0000 (UTC)
Subject: [whatwg] Editorial: parsing section
In-Reply-To: <op.tgf15rmfaw9dld@id-c0020.oslo.opera.com>
References: <op.tfn81ebkaw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.62.0609211934140.21538@dhalsim.dreamhost.com>
	<op.tgdi9jqraw9dld@localhost>
	<Pine.LNX.4.62.0609250145330.13053@dhalsim.dreamhost.com>
	<op.tgfi961raw9dld@id-c0020.oslo.opera.com>
	<Pine.LNX.4.62.0609251700340.13053@dhalsim.dreamhost.com>
	<op.tgf15rmfaw9dld@id-c0020.oslo.opera.com>
Message-ID: <Pine.LNX.4.62.0609251733200.13053@dhalsim.dreamhost.com>

On Mon, 25 Sep 2006, Anne van Kesteren wrote:
>
> On Mon, 25 Sep 2006 19:01:34 +0200, Ian Hickson <ian at hixie.ch> wrote:
> > > Anyway, perhaps you should have a note somewhere to make this more clear?
> > 
> > I'm not sure what the note would be and where it should go... can you
> > suggest some text and a location? I'd love to make this clearer but I'm
> > probably too close to it to understand how to do so.
> 
> After the first paragraph of section 8.2.4.3.6. you could have something like:
> 
>   Besides everything noted in the specific insertion mode
>   covered by "Anything else" in "How to handle tokens in
>   the main phase" the other items in that section are to
>   considered as well when handling the specific insertion
>   mode, such as a DOCTYPE token.

I'm not sure I understand what that means. :-)

It just struck me that maybe I should just fold all the insertion modes 
into phases and be done with it (and duplicate those two common rules 
across all the "insertion modes"). Maybe I'll do that. I've added an issue 
about doing that for now.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Mon Sep 25 21:23:25 2006
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 26 Sep 2006 04:23:25 +0000 (UTC)
Subject: [whatwg] WF2: Clarification on valueMissing requested
In-Reply-To: <9301ed6b0609200105l555f6fbbu48da0dfd17a0c349@mail.gmail.com>
References: <9301ed6b0609200105l555f6fbbu48da0dfd17a0c349@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0609260358520.4336@dhalsim.dreamhost.com>

On Wed, 20 Sep 2006, Alex Vincent wrote:
>
> "The field has the required  attribute set but has no value selected."
> 
> In implementing this for Mozilla, I realized an edge case that could
> prove troublesome.  Specifically, what happens if you have multiple
> radio or checkboxes with the required attribute and no boxes checked
> for any of them.
> 
> Alternatively, consider when the radio button is checked but doesn't
> have a value... and some other radio input with the same name in the
> same form does have a value.
> 
> There's an attempt to clarify it here:
> 
> "When a radio group has no checked radio button and more than one of
> the radio buttons is marked as required, the UA should only tell the
> user that the radio group as a whole is missing a value, not complain
> about each radio button in turn, even though all of the radio buttons
> marked with the required attribute would have the valueMissing flag
> set."
> 
> Tell the user how?  Visually?  Through DOM events?  Both, or some
> other way?  I'm working from the DOM events view right now, and this
> could be the difference between dispatching one event and dispatching
> many.

Clarified.

Let me know if that doesn't help.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ajvincent at gmail.com  Fri Sep 29 22:42:26 2006
From: ajvincent at gmail.com (Alex Vincent)
Date: Fri, 29 Sep 2006 22:42:26 -0700
Subject: [whatwg] WF2 clarification request: File upload controls
Message-ID: <9301ed6b0609292242h4bb22c6dg54c7c032572710a2@mail.gmail.com>

In the past, user agents have allowed file upload controls to
reference files not local to the computer in question.  For validity
purposes, I wonder if this should still be allowed under Web Forms
2.0.

Allowing remote values in the file upload control could be a
performance hit via networking, since we'd have to verify the file
exists before saying valueMissing is false...

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001


From canvasgame at gmail.com  Sat Sep 30 07:29:52 2006
From: canvasgame at gmail.com (Benjamin Joffe)
Date: Sun, 1 Oct 2006 00:29:52 +1000
Subject: [whatwg] Opera canvas bug?
Message-ID: <f9ec6ebb0609300729w2fb0d420qf03f3ad243808143@mail.gmail.com>

I have set up a few pages to demonstrate bugs with Opera's canvas
implementation. You can see it here:
http://abrahamjoffe.com.au/ben/opera_canvas_bugs/index.htm , I am sure that
the first 3 are genuine Opera bugs but the 4th one might not be because I do
not think that the WhatWG spec is specific enough with nested clipping
paths, none-the-less I feel that the way Firefox handles the script is more
correct than how Opera does. Would you agree?

Regards,
Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20061001/35a06f21/attachment-0001.htm>