[whatwg] Only allow md5WithRSAEncryption with ?

[Adam Roben]

HTML5 currently says that the signature algorithm used with keytype=rsa> should be any of "those listed in section 2.2.1 ('RSA  
Signature Algorithm') of RFC 3279."


However, both WebKit and Gecko only ever use the md5WithRSAEncryption  
signature algorithm. And apparently WebKit ran into compatibility  
issues with MIT's websites back in 2004 when it tried to use the id- 
sha1 signature algorithm instead.


I'd recommend that HTML5 change to say that only the  
md5WithRSAEncryption signature algorithm should be used for keytype=rsa>.


-Adam

[whatwg] Unifying DOMTokenList with DOM 3 Core's DOMStringList?

[Adam Roben]

DOM 3 Core defines the DOMStringList interface [1], which has some  
similarities to HTML 5's DOMTokenList interface. In fact,  
DOMStringList basically provides a subset of DOMTokenList's  
functionality. But there is a mismatch in the names of the  
DOMTokenList.has and DOMTokenList.contains methods (which seem to have  
the same purpose).


I think DOMTokenList.has should be renamed to DOMTokenList.contains,  
to match DOMStringList.


Perhaps some relationship between these two interfaces should be  
defined as well (though that would obviously introduce a dependency on  
DOM 3 Core).


-Adam

[1] 
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#DOMStringList

[whatwg] Definitions of DOMTokenList algorithms and element.classList

[Adam Roben]

Step 3 of the algorithm for DOMTokenList.has says:

If the token indicated by token is one of the tokens in the object's  
underlying string then return true and stop this algorithm.


What does "token is one of the tokens" mean? I assume it means that a  
case-sensitive string comparison of token with each of the tokens in  
the DOMTokenList yields one match. It might be good to clarify this in  
the spec. Note that the algorithms for DOMTokenList.add and  
DOMTokenList.toggle use similar wording.


Should methods of element.classList treat their arguments case- 
insensitively in quirks mode? I think they should. This should be  
mentioned in the spec.


-Adam

Re: [whatwg] More random comments on the putImageData definition

[Adam Roben]

On Jan 25, 2008, at 6:56 AM, Oliver Hunt wrote:

With the current model for putImageData there is no way for them to  
specify a dirty rect, which means their only option is to update the  
entire display -- they have to copy the entire buffer.




Anyway, i was thinking we would just need to putDataImage methods:
void putImageData(in ImageData imagedata, in float dx, in float dy);
void putImageData(in ImageData imagedata, in float dx, in float dy,  
in float dirtyX, in float dirtyY, in float dirtyWidth, in float  
dirtyHeight);


Where the dirtyX and dirtyY are relative to the ImageData's origin.

The repaint region would be (dx+dirtyX, dy+dirtyY),  
dirtyWidth*dirtyHeight in the canvas domain


I think it would be less confusing for the repaint region to always  
have its origin at (dx, dy). This would be more similar to Windows'  
BitBlt API. Something like:


void putImageData(in ImageData imageData, in float destX, in float  
destY, in float srcX, in float srcY, in float width, in float height)


destX and destY are in canvas coordinates
srcX and srcY are in ImageData coordinates

The data from the ImageData in the rectangle specified by (srcX, srcY,  
width, height) is then painted into the canvas in the rectangle  
(destX, destY, width, height).


-Adam

Re: [whatwg] How to use SVG in HTML5?

[Adam Roben]

On Jan 23, 2008, at 9:55 AM, David Gerard wrote:


On 23/01/2008, James Graham <[EMAIL PROTECTED]> wrote:

In browsers which support it  will work (with  
certain

limitations for security reasons).



 is just what I was hoping for, thank you :-) Doesn't
yet seem to work in Safari 3.0.4, SeaMonkey 1.1.7 or Minefield
(Firefox 3 nightly) 2008012304 on Windows, though. Are there browsers
it currently does work in?


This should also work in WebKit nightly builds (available from ).


-Adam

Re: [whatwg] several messages regarding Ogg in HTML5

[Adam Roben]

alex wrote:
> Ogg is not necessarily the only solution that avoids patent > 
encumbrence. There are codecs that have been in existence for longer 
> than the patent lifetime, for instance. Dave Singer posted a quite 
> thorough analysis of this issue recently.


I have seen this argument pop up now and again, but I have failed to 
actually find the URL to this, could someone post it please?


I believe this is the email to which people have been referring:

http://lists.w3.org/Archives/Public/public-html/2007Nov/0153.html

-Adam

Re: [whatwg] Comments on updated SQL API

[Adam Roben]

I think the conversation in this thread has gotten a little muddled.  
The two main issues I see being discussed are:


1. Should single SQL statements be wrapped in a transaction?
2. Should the SQL API support explicit transactions (and therefore a  
way to not fall into implicit transactions)?


It sounds like Brady is mostly concerned about (1), while Scott is  
mostly concerned about (2). I think it would be helpful to discuss  
these as separate issues.


-Adam

On Oct 17, 2007, at 11:24 AM, Brady Eidson wrote:



On Oct 17, 2007, at 11:04 AM, Scott Hess wrote:


On 10/17/07, Brady Eidson <[EMAIL PROTECTED]> wrote:

Assuming using sqlite for the back end, I just wrote a quick little
driver that creates a table with 10 columns, then inserts the exact
same value into the table 20,000 times.
I then ran the exact same test that does the exact same thing, but
wraps each individual insert in a transaction.

The transaction case is 5% slower.


But in this case, if you inserted the values 1,000 per transaction,  
it

would probably be 10x faster.  Maybe 100x faster if you're dealing
with a network filesystem.


I agree completely.  The debate is not whether transactions speed up  
batch queries.  It's whether they slow down individual queries -  
which I have evidence saying they do.
My point is that if we can all end up agreeing it is a performance  
hit, then it is an agreed upon mark against the *implicit*  
transaction.



The performance case for not using implicit transactions for server
databases is that it can allow for more concurrency.  If the client
sends a statement to the server without an enclosing transaction, the
server can minimize the amount of time the transaction has the
database/table/row locked.  If the client has to open the  
transaction,

that means a minimum of two additional round trips back to the client
are introduced (and much worse, if either the client or server are
very busy).


I'm also concerned about this - the same will be true with SQLite  
(minimizing the amount of time a write lock is maintained on the  
database file)



For an embedded database like SQLite, things are different.  In that
case, no matter what, you're going to pay a big cost for fsync.
Making the transaction explicit will have an impact, but I'm really
surprised that you're seeing 5%.  I would bet that you're doing BEGIN
rather than BEGIN IMMEDIATE, which means that your 5% is probably  
down
to upgrading your database locks.  If so, that can be worked around  
by

implementing the spec using BEGIN IMMEDIATE rather than BEGIN
DEFERRED.


I will run more detailed numbers on this later, but a quick 1-off on  
changing it to BEING IMMEDIATE still indicates a measurable  
slowdown, between 1% and 2%



For the current spec, concurrency isn't a huge issue, because
everything will be serialized at some level anyhow.


Nothing in the current spec forces 2 different browsing contexts  
from operating concurrently, resulting in the possibility of their  
own transactions stomping each other.


[Sorry, don't mean to sound like I'm flip-flopping.  My concerns  
about

implicit transactions aren't really performance related. :-).]


My concerns about them are more than just performance related ones.   
A forced performance penalty just drives me mad ;)


~Brady

Re: [whatwg] Comments/questions on 4.6 Offline Web applications

[Adam Roben]

Darin Adler wrote:

On Oct 12, 2007, at 6:11 AM, Adam Roben wrote:

It may be worth stating in this section what the behavior is when a 
section or opportunistic caching namespace appears multiple times. 
The parsing algorithm makes this clear, but it would be clearer 
still to also state the behavior in this section.


Well, that would be non-conforming. I'm not sure we want to tell 
authors what the error handling behaviour is when they ignore the 
conformance requirements... do we?


I see. I was not looking at this part of the spec from an application 
author's perspective. In light of that, I think the current level of 
detail is appropriate.


Our experience with HTML has taught us that authors don't necessarily 
read the specifications nor conform. The behavior of web browsers when 
application authors ignore conformance requirements may be quite 
important to compatibility in practice; if it's not specified then the 
applications end up relying on the behavior of the implementation they 
test with.


So I think it's worth considering being explicit about the error 
handling. Not necessarily "for the authors", but for the benefit of 
the web browser implementers.


The error handling behavior is explicit in the parsing algorithm. 
Perhaps it's not explicit as you would like, though?


-Adam

Re: [whatwg] Comments/questions on 4.6 Offline Web applications

[Adam Roben]

Ian Hickson wrote:

On Sat, 6 Oct 2007, Adam Roben wrote:
  
Here are some comments and questions about section 4.6 Offline Web 
applications:



Thanks for the feedback! It was very useful in making the spec better. 
Please do continue reviewing the spec!
  


Glad to hear it!


Can javascript: URIs be specified in the manifest?



I guess currently this is allowed...

I'm not sure how to work around this. Blacklisting them is a bad idea, as 
we'll forget some scheme that should be black-listed (e.g. vbscript:). 
Should we just say that you can only cache files that have the same scheme 
as the manifest? I've said that for now.
  


That sounds reasonable to me.

It may be worth stating in this section what the behavior is when a 
section or opportunistic caching namespace appears multiple times. The 
parsing algorithm makes this clear, but it would be clearer still to 
also state the behavior in this section.



Well, that would be non-conforming. I'm not sure we want to tell authors 
what the error handling behaviour is when they ignore the conformance 
requirements... do we?
  


I see. I was not looking at this part of the spec from an application 
author's perspective. In light of that, I think the current level of 
detail is appropriate.



4.6.4
-
Steps 8.2 and 19.3.2 say that the user agent should "discard cache". What does
"discard cache" mean (in the case of an upgrade attempt, "cache" is a possibly
in-use cache)?



The "discard cache" step is never reached when "cache" is in use. Is the 
meaning really ambiguous? I'm not sure how else to say it.
  


Somehow my eyes skipped over the phrase "If this is a cache attempt". In 
the case of a cache attempt, I think "discard" is perfectly clear.



Step 19 should specify what should happen if a URI that is already in the
cache's online whitelist is to be added as an explicit, fallback, or dynamic
entry.



(Now step 20.) It does. Which is to say, it being on the online whitelist 
has no effect. Should it have an effect? We can omit the caching of such 
files if you want.
  


Given that section 4.6.5.1 says that resources in the online whitelist 
are always fetched from the network, it seems that caching any resource 
that is in the online whitelist is simply a waste of time and space. I 
guess there's no need to explicitly state that such resources should not 
be cached -- implementors could design their implementation that way as 
an optimization.


-Adam

Re: [whatwg] Comments/questions on 4.6 Offline Web applications

[Adam Roben]

On Oct 6, 2007, at 2:31 PM, Adam Roben wrote:


4.6.2
-
Can javascript: URIs be used entries?


Sorry, that should have said:

Can javascript: URIs be specified in the manifest?

-Adam

[whatwg] Comments/questions on 4.6 Offline Web applications

[Adam Roben]

Here are some comments and questions about section 4.6 Offline Web  
applications:


4.6.2
-
The description of "Implicit entries" is unclear. My current  
understanding is that the only kind of implicit entry you ever have is  
a document that specified an application attribute on its html  
element. The description of "The manifest" and the application cache  
selection algorithm seem to support this. I think my confusion would  
be cleared up if the first word in the description of "Implicit  
resources" were "Documents" instead of "Resources".


Can javascript: URIs be used entries?

4.6.3.1
---
"Manifests must specify all the URIs that are to be cached" seems to  
be untrue: you don't have to specify the URI of any implicit  
resources, or of the manifest itself.


It may be worth stating in this section what the behavior is when a  
section or opportunistic caching namespace appears multiple times. The  
parsing algorithm makes this clear, but it would be clearer still to  
also state the behavior in this section.


4.6.3.2
---
Section 4.6.3.1 says that the initial "CACHE MANIFEST" line may have  
zero or more trailing space or tab characters, but step 9 of the  
parsing algorithm says that trailing whitespace is disallowed.


Step 19: Beneath 'If mode is "fallback"', there are two places where  
the phrase "opportunistic caching namespaces" is used. In both cases,  
"namespaces" should be replaced with "namespace".


Step 19 should specify what the user agent's behavior should be when  
an explicit or fallback URI is encountered which was already  
encountered in an online whitelist section, or when an online  
whitelist URI is encountered that was already encountered in an  
explicit or fallback section.


Step 21 of the parsing algorithm should end with "and the online  
whitelist URIs" instead of "and the online URIs".


4.6.4
-
Steps 8.2 and 19.3.2 say that the user agent should "discard cache".  
What does "discard cache" mean (in the case of an upgrade attempt,  
"cache" is a possibly in-use cache)? In step 19.3.2, what is to be  
done with "new cache"?


Step 19 should specify what should happen if a URI that is already in  
the cache's online whitelist is to be added as an explicit, fallback,  
or dynamic entry.


Step 22 should specify what should happen if a URI that is already in  
the cache as an explicit, fallback, or dynamic entry is to be added to  
the cache's online whitelist.


It would be good to make it clear in steps 19.{5,6,7,8} that an entry  
can end up in multiple categories.


4.6.5.1
---
What happens if the resource's URI is a javascript: URI? This seems  
particularly interesting in the case of fallback URIs.


4.6.6
-
Small typo in the description of the length attribute: "and zero the  
object is not associated..." should have the word "if" between "zero"  
and "the".


The description of the length attribute says "The length attribute  
must return the number of entries in the application cache...", but  
should I think say "The length attribute must return the number of  
_dynamic_ entries in the application cache..." to be consistent with  
subsequent paragraphs.


What happens if you add() a URI that is in the online whitelist?

Should an exception be thrown if remove() is called with a URI that is  
not a dynamic entry?


In the definition of swapCache(), the Note in step 2 is unclear when  
it says "this can only happen if...", as "this" could be interpreted  
as either "success" or "abortion". I believe "success" is the correct  
interpretation, but it would be nice to be clearer here.


-Adam

[whatwg] Typo in last paragraph of Acknowledgements

[Adam Roben]

"Thanks also the Microsoft blogging community"

should be

"Thanks also to the Microsoft blogging community"

-Adam

[whatwg] HTMLTableElement should have a createTBody method

[Adam Roben]

   The omission of a createTBody method from HTMLTableElement makes  
it rather inconvenient to create a table with both a thead and a tbody  
using the table DOM APIs. After creating a thead, you have to manually  
create and append the tbody to start putting rows into the body of the  
table, so you cannot exclusively use the HTMLTableElement methods to  
populate the table. If a createTBody method is added, I'd suggest that  
it always create a new tbody rather than ever returning an existing one.


-Adam