Re: [whatwg] Scripting Tweaks

[liorean]

> On Wed, 20 Apr 2005, Dean Edwards wrote:
>> 1) Mozilla's DOMContentLoaded event is very handy. It fires when a
>> node's content has been loaded and parsed (the DOM has been
>> constructed). This is much better than the standard onload event as
>> it
>> doesn't wait for binary content to also load.



On May 18, 2007, at 3:40 PM, Ian Hickson wrote:
> Added.


On 19/05/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

FYI this was considered and rejected by the Web API Working Group at
W3C for inclusion in DOM Events, I believe because there did not seem
to be a truly valid use case (a popular use of this event is for late
binding of script, but given the event definition and the existence of
incremental rendering you can't actually be guaranteed the event will
fire before any content has rendered - XBL2 potentially provides a
better solution). I suggest referring to these discussions.


True, but what is wanted by scripters isn't that it triggers before
any rendering takes place at all, what is wanted by scripters is to
not have to wait for external content to load, in difference to the
load event. The important factors are that the DOM is not incomplete
and that it takes place as soon as possible, not that rendering hasn't
started - because most often it's wanted specifically for DOM
manipulation.


Also, 

Re: [whatwg] Scripting Tweaks

[liorean]

On 19/05/07, Ian Hickson <[EMAIL PROTECTED]> wrote:

> 3) I find myself using Microsoft's uniqueID property quite often. Although the
> ID attribute is supposed to provide a unique identifier, it often doesn't. We
> would probably need a complementary DOM method to retrieve an element by
> uniqueID (IE uses the "all" property).
>
> 
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/uniqueid.asp
>
> If I want to build a list of elements that I've already processed:
>
> var processed = {};
> for (var i in elements) {
>   if (!processed[elements[i].uniqueID]) {
> process(elements[i]);
> processed[elements[i].uniqueID] = true;
>   }
> }
>
> I can't think of another way of doing that.

   for (var i in elements) {
 if (!elements[i].processed) {
   process(elements[i]);
   elements[i].processed = true;
 }
   }
   for (var i in elements)
 delete elements[i].processed;

The "uniqueID" thing is really working around a deficiency in JS
(inability to use objects as keys). I think that's where it should be
addressed. The uniqueID idea has a number of rather unique implementation
difficulties. The obvious implementations have security and privacy
implementations; the solutions to those tend to be expensive either in RAM
or CPU. I recommend bringing this to the attention of the ES4 group.


ES4 already has something of the kind. See
http://developer.mozilla.org/es4/proposals/hashcodes.html>

However, that is not usable in ES3 implementations, which uniqueID is.





Besides, the problem is solvable without polluting the objects by
adding property through using one object for storing processed
elements and one object for the full set of elements. Then you can use
something like

   processed_elements[key]=all_elements[key];

for storing that an element is processed,

  delete processed_elements[key];

to remove an element from the processed elements list, and something like

   for(key in all_elements)
   if(!(processed_elements.hasOwnProperty(key)))
   process(key);

to iterate through the unprocessed elements.
--
David "liorean" Andersson

Re: [whatwg] Scripting Tweaks

[Ian Hickson]

On Fri, 18 May 2007, Maciej Stachowiak wrote:
> > > 
> > > 1) Mozilla's DOMContentLoaded event is very handy. It fires when a 
> > > node's content has been loaded and parsed (the DOM has been 
> > > constructed). This is much better than the standard onload event as 
> > > it doesn't wait for binary content to also load.
> > 
> > Added.
> 
> FYI this was considered and rejected by the Web API Working Group at W3C 
> for inclusion in DOM Events, I believe because there did not seem to be 
> a truly valid use case (a popular use of this event is for late binding 
> of script, but given the event definition and the existence of 
> incremental rendering you can't actually be guaranteed the event will 
> fire before any content has rendered - XBL2 potentially provides a 
> better solution). I suggest referring to these discussions.

I was one of the people who said the use cases weren't convincing. :-)


> Also, 

Re: [whatwg] Radio UserLand: Mail from Ian Hickson

[Maciej Stachowiak]

On May 18, 2007, at 4:19 PM, Ian Hickson wrote:


On Fri, 22 Apr 2005, Brad Neuberg wrote:


Here's a possible API for GET and POST semantics without  
XmlHttpRequest:


window.location.href = base URL + URL parameters already appended
window.location.method = GET or POST, nothing else supported

If the method is a POST method, the internal code simply pulls all  
the

parameters off of window.location.href and builds up a POST request
using them.  Should it URL encode each query parameter and key  
first, or

assume that they are already URL-encoded?


Would this just be to do a scripted navigation to a POST page?

A .method property on 'location' is an interesting idea, but it would
probably end up confusing (what if you set it and another script  
does a

.href="" thinking it will do a GET?).


I think parsing the query part of a URL to resubmit as an http post  
body is also in general inappropriate, since one may validly POST data  
to a URL with a query part. Granted this is an edge case but there are  
certainly cleaner ways to supply a body.


window.location.post() is probably the best plan if we want to do  
this, I

think. The question is, what exactly is the use case? Do we want to be
doing POSTs like this without the user knowing, and with JS required?


Even without use of JS, you could style a  for a  
form of otherwise hidden fields to look like a link, to make something  
that posts but looks like a normal link. To submit programatically,  
you can dynamically create a form. For cases where that is not a good  
way to build up the post body, an explicit location.post() method (or  
more generally location.load that takes URI, method, body and headers)  
would indeed be better than using multiple properties of the location  
object.


Regards,
Maciej

Re: [whatwg] Scripting Tweaks

[Maciej Stachowiak]

On May 18, 2007, at 3:40 PM, Ian Hickson wrote:


On Wed, 20 Apr 2005, Dean Edwards wrote:


1) Mozilla's DOMContentLoaded event is very handy. It fires when a
node's content has been loaded and parsed (the DOM has been
constructed). This is much better than the standard onload event as  
it

doesn't wait for binary content to also load.


Added.


FYI this was considered and rejected by the Web API Working Group at  
W3C for inclusion in DOM Events, I believe because there did not seem  
to be a truly valid use case (a popular use of this event is for late  
binding of script, but given the event definition and the existence of  
incremental rendering you can't actually be guaranteed the event will  
fire before any content has rendered - XBL2 potentially provides a  
better solution). I suggest referring to these discussions.


Also, 

Re: [whatwg] Radio UserLand: Mail from Ian Hickson

[Ian Hickson]

On Fri, 22 Apr 2005, Brad Neuberg wrote:
>
> Here's a possible API for GET and POST semantics without XmlHttpRequest:
> 
> window.location.href = base URL + URL parameters already appended 
> window.location.method = GET or POST, nothing else supported
> 
> If the method is a POST method, the internal code simply pulls all the 
> parameters off of window.location.href and builds up a POST request 
> using them.  Should it URL encode each query parameter and key first, or 
> assume that they are already URL-encoded?

Would this just be to do a scripted navigation to a POST page?

A .method property on 'location' is an interesting idea, but it would 
probably end up confusing (what if you set it and another script does a 
.href="" thinking it will do a GET?).

window.location.post() is probably the best plan if we want to do this, I 
think. The question is, what exactly is the use case? Do we want to be 
doing POSTs like this without the user knowing, and with JS required?

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

Re: [whatwg] Radio UserLand: Mail from Ian Hickson

[Ian Hickson]

On Fri, 22 Apr 2005, Jon Udell wrote:
> 
> OK. Then I do propose an easy way to issue a non-interactive HTTP POST.

There are two ways to do it today; XMLHttpRequest and dynamic  
creation. The former allows for behind-the-scenes stuff and the latter 
is needed when you want to replace the current page.

Could you elaborate on the use case? It would be helpful to work out 
exactly what you're trying to do so that we can add the right feature to 
the language.

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

Re: [whatwg] Scripting Tweaks

[Ian Hickson]

On Wed, 20 Apr 2005, Dean Edwards wrote:
> 
> 1) Mozilla's DOMContentLoaded event is very handy. It fires when a 
> node's content has been loaded and parsed (the DOM has been 
> constructed). This is much better than the standard onload event as it 
> doesn't wait for binary content to also load.

Added.


> 2) I'd like to be able to lock/disable an entire document. This is 
> useful when submitting to hidden frames. It helps prevent users from 
> re-submitting data before it has been processed. Ideally, I could 
> disable an entire frameset. Better yet, I can display some kind of 
> visual feedback so that the user knows the page is locked (e.g. 
> hourglass, greyed out content).

I considered this some more, and it really seems that giving the author an 
explicit way to disable the entire content is somewhat against some of the 
principles of the Web. You can work around the lack of this by having a 
 that you position using CSS over the whole viewport, or by 
disabling all submit buttons, or putting all buttons in a  and 
disabling that, or any number of other mechanisms, but I don't think we 
should have a way to disable the page. I can just imagine the kinds of 
problems that would occur if this were to be introduced.


> > Most GUI applications don't have the possibility of the network dying 
> > and never re-enabling the page. :-)
> 
> True. However, if the network dies the page is not going to reflect that 
> anyway.

Actually now it could; we've introduced events to handle that case.


> 3) I find myself using Microsoft's uniqueID property quite often. Although the
> ID attribute is supposed to provide a unique identifier, it often doesn't. We
> would probably need a complementary DOM method to retrieve an element by
> uniqueID (IE uses the "all" property).
> 
> http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/uniqueid.asp
>
> If I want to build a list of elements that I've already processed:
> 
> var processed = {};
> for (var i in elements) {
>   if (!processed[elements[i].uniqueID]) {
> process(elements[i]);
> processed[elements[i].uniqueID] = true;
>   }
> }
> 
> I can't think of another way of doing that.

   for (var i in elements) {
 if (!elements[i].processed) {
   process(elements[i]);
   elements[i].processed = true;
 }
   }
   for (var i in elements)
 delete elements[i].processed;

The "uniqueID" thing is really working around a deficiency in JS 
(inability to use objects as keys). I think that's where it should be 
addressed. The uniqueID idea has a number of rather unique implementation 
difficulties. The obvious implementations have security and privacy 
implementations; the solutions to those tend to be expensive either in RAM 
or CPU. I recommend bringing this to the attention of the ES4 group.

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

Re: [whatwg]

[David Hyatt]

If  were to be standardized, Apple would need this  
done in a way that would be backwards-compatible with our current  
syntax.  Otherwise we'd be forced to require an opt-in mode for HTML5  
(and that is really not something we want to have to do).


dave
([EMAIL PROTECTED])

On May 17, 2007, at 11:53 PM, Matthew Paul Thomas wrote:


On May 18, 2007, at 12:43 PM, Lachlan Hunt wrote:

...
* class="search"

The aim of this one was to be able to indicate the form  
specifically used for searching. This would then allow UAs,  
especially assistive technology, to implement keyboard shortcuts  
or other mechanisms for taking the user directly to the search  
form.  role="search" is provided by the role attribute spec for a  
similar purpose, and Safari also has .  I  
would prefer the new input type because it also has direct  
benefits for regular users, not just those with assistive technology.

...


I agree, why not add ? The use cases are:
*   Better accessibility, as described above by Lachlan.
*   People often scan Web pages looking for "the little box where I  
can
type".  If site  
search
fields were visibly different from other text fields, and  
different
*in a consistent way across sites*, that would make people  
faster at

using those sites.

There are also ill effects from it *not* being standardized. Web  
authors often use brittle CSS in an attempt to emulate the Mac OS X  
or Windows Vista search field look.



 (see the top of the page)
They're brittle in the sense that they have cosmetic differences  
from the native controls, they sometimes rely on JavaScript, they  
fall apart when the page is zoomed, and/or they don't zoom at all.  
(Safari's implementation in 1.3/2.0 also doesn't zoom, but that  
could be fixed much more easily in WebKit -- if it hasn't been  
already -- than in a CSS+PNG+JS imitation.)


I can think of one potential problem, that being Web authors trying  
to use  for fields that aren't search fields  
because they think it looks cool (and because they don't use  
assistive aids themselves, so they don't realize the silliness).  
That problem would be inversely proportional to how much browsers  
made the field behave unalterably like a search field.




* class="error"

The original idea for this was for indicating error messages,  
particularly related form fields.  The problem is that screen  
readers, when in forms mode, only read the content of form control  
labels, which has resulted in authors having to write any error  
messages within labels, which is kind of a hack.  Labels and error  
messages should be able to be separated and providing a way to  
specifically indicate them would allow screen readers to indicate  
their presence to the user and read it on request.

...


Maybe that should be addressed (in Web Forms 3?) with a specific  
 element.


Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/