Re: [whatwg] 2.20.2 The command element - icon attribute

2006-03-02 Thread ROBO Design
On Thu, 02 Mar 2006 09:18:18 +0200, Matthew Raymond  
[EMAIL PROTECTED] wrote:



ROBO Design wrote:

...


   I think the idea is that the command element is defining the icon
to appear for any element that has a |command| attribute defined. That
said, you could probably replace it with the following CSS:

| command#myID::before, *[command=myID]::before {
|   content: url(icon.png);
| }

   So, I guess I'm inclined to agree with you...


Yes, exactly. Icons can be added today to any element in various ways.

I simply don't see the need for the icon attribute, as a semantical  
purpose.


--
http://www.robodesign.ro
ROBO Design - We bring you the future


Re: [whatwg] Content Restrictions

2006-03-02 Thread Alexey Feldgendler
On Tue, 21 Feb 2006 10:31:51 +0600, Hallvord Reiar Michaelsen Steen  
[EMAIL PROTECTED] wrote:



What is or what isn't technically simple to implement in existing
implementations should perhaps not be what decides how specifications  
are

written.  It is clear that it is possible to implement per-function
security tracking (though slightly unclear how such security tracking
should work; which of all currently executing functions determine the
security context?)


Only the innermost one does. I've posted the exact rules a couple of weeks  
ago.


 It is also clear that it hasn't been exactly been required by  
implementations
yet, so it is likely that an implementation doesn't have it already.   
And since
it involves storing more information, implementing it is likely to cost  
some

in terms of memory use.


In Gecko, as far as I can see from its source code, it doesn't add memory  
overhead. It already has origin tracking of some kind (used to implement  
the today's usual security restrictions).



why doesn't the author simply make
sure to serve the untrusted content from another server (with another
host name or port number, that is, not necessarily another machine)?


This is what LiveJournal does now. However:
1. For many small sites it's not an option,
2. It doesn't solve the problem of untrusted JS included by a page.


Seems that brings another (although simpler) set of problems though:
what if the untrusted content contains a /SANDBOX tag, or if it
ends with !--, or possibly other syntax anomalies?


I never said that the website won't have to do HTML cleaning for  
user-supplied content. But with HTML 5 reference parsing algorithm, such  
cleaning is going to be much easier and straightforward: parse the text  
into DOM (as if it was inside BODY, for example), remove or modify  
forbidden elements, then serialize it. That way, /SANDBOX will be  
ignored as an easy parse error because it doesn't match an opening tag  
within the user-supplied text. An unclosed comment will be ignored, too.



What if it doesn't contain exactly that, but something else that
triggers equivalent behaviour in the HTML parser in some implementation?
HTML parser are traditionally quite complex, and quite fuzzy.  The
fuzziness hasn't been a security problem before, now all of a sudden it
might be.


HTML 5 will make HTML parsing in standards mode well-defined, with  
predictable error recovery.



Did we discuss how the UA should handle a closing /sandbox tag?
Would it need to scan forward in the markup to find other closing
tags and determine if the current one is a part of the enclosed
markup or the end of the SANDBOX in that page? Perhaps only the first
and the last SANDBOX open/close tags can be taken into account and
others discarded?


No need to do that. SANDBOX elements can be nested like many others.  
Nevertheless, a /SANDBOX tag without a matching opening tag inside the  
user-supplied content will be ignored during the HTML cleanup process  
described above.


There is one more such case: when /SANDBOX is injected using  
document.write(/SANDBOX), but that can be easily circumvented.



--
Opera M2 8.5 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station [ICQ: 115226275] [EMAIL PROTECTED]


Re: [whatwg] anchor(jump) DOM Event proposal

2006-03-02 Thread Ric Hardacre



Flow of events:
- When the page is loaded, and an anchor event listener exists, the 
anchor event will be fired after the load event. If there is no anchor 
in the URL, the event.anchorName property will be an empty string.
- When an anchor link is clicked, the anchor event listener (if exists) 
will be fired
- The event handler can get the name of the anchor via event.anchorName 
(which will contain the string after the hash)
- If the return value from the handler is true, the traditional form of 
operation (the jumping to the anchor) will occur next; otherwise, that 
step is skipped.
- The UA should act as if the navigation has gone forward a page (add 
history, etc).
- If the user navigates back and the previous page happens to be the 
same page but a different anchor, the anchor event again will be fired 
as if the previous anchor was freshly navigated to. The same logic 
applies to navigating forward.


sounds good, and logical when compared with anchor and button onclick 
for example.


to clarify, where would the event be attached by default? document or 
window? i.e. would i


function myonAnchor( e )
{
if( e.anchorName )
switch( e.anchorName )
{

...

default:
return true;
}
}

document.onAnchor = myonAnchor;

---

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





Re: [whatwg] 2.20.2 The command element - icon attribute

2006-03-02 Thread dolphinling

Matthew Paul Thomas wrote:
The difference between select and input type=radio ... input  
type=radio is purely presentational. The difference between select  
multiple and input type=checkbox ... input type=checkbox is  
purely presentational. ... That doesn't mean they shouldn't all exist.


They *shouldn't* all exist. There should only be select and select 
multiple, stylable with XBL*. The only reason they do exist is for 
backwards compatibility.


The difference between input type=text and input type=password 
is purely presentational. 


No. password is a narrow subcase of text. It's like the difference 
between blue and #aa



* Actually, it should probably be input type=select and input 
type=multiselect. But again, backwards comaptibility.


--
dolphinling
http://dolphinling.net/