Re: [whatwg] Adding a src attribute to all elements

[Michael A. Puls II]

On Tue, 03 Nov 2009 23:50:43 -0500, Tab Atkins Jr.   
wrote:


On Tue, Nov 3, 2009 at 8:21 PM, Michael A. Puls II  
 wrote:
On Tue, 03 Nov 2009 21:05:26 -0500, Curtiss Grymala  


wrote:

For instance, if I create a level 1 header that looks like:
This is a header
The text "This is a header" would be replaced with the image that's
located at /example.png. However, if /example.png returns a 404 error,
the text would be displayed instead.


Opera supports this with css extensions.


This is supported in the CSS specs properly, via the content property.

*[src] {
  content: attr(src,url);
}

Done.  (Doesn't work yet anywhere I believe, but it will.)


Cool. Thanks

--
Michael

Re: [whatwg] Adding a src attribute to all elements

[Tab Atkins Jr.]

On Tue, Nov 3, 2009 at 8:21 PM, Michael A. Puls II  wrote:
> On Tue, 03 Nov 2009 21:05:26 -0500, Curtiss Grymala 
> wrote:
>> For instance, if I create a level 1 header that looks like:
>> This is a header
>> The text "This is a header" would be replaced with the image that's
>> located at /example.png. However, if /example.png returns a 404 error,
>> the text would be displayed instead.
>
> Opera supports this with css extensions.

This is supported in the CSS specs properly, via the content property.

*[src] {
  content: attr(src,url);
}

Done.  (Doesn't work yet anywhere I believe, but it will.)

~TJ

Re: [whatwg] Adding a src attribute to all elements

[Nils Dagsson Moskopp]

Am Tue, 03 Nov 2009 23:21:35 -0500
schrieb "Michael A. Puls II" :

> I don't feel super strongly about it though. I just think it'd be  
> nice/cool.
 
And I want a Pony !! ;)

-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] Adding a src attribute to all elements

[Michael A. Puls II]

On Tue, 03 Nov 2009 21:05:26 -0500, Curtiss Grymala   
wrote:



I would like to propose that a src attribute be added to the spec for
all HTML elements. The content of the file referenced in the src
attribute would then replace the contents of the element that contains
the src attribute. The src attribute would then be interpreted
differently, depending on the type of file referenced in that src
attribute.

For instance, if I create a level 1 header that looks like:
This is a header
The text "This is a header" would be replaced with the image that's
located at /example.png. However, if /example.png returns a 404 error,
the text would be displayed instead.


Opera supports this with css extensions.

For example:



*[src] {
-o-replace: attr(src);
width: attr(width);
height: attr(height);
display: inline-block;
border: 1px solid black;
}
*[href] {
-o-link: attr(href);
-o-link-source: current;
display: inline;
text-decoration: underline;
color: blue;
}
/* in XML */
image_link[src] {
-o-link: attr(src) !important;
-o-link-source: current;
-o-replace: attr(src);
display: inline-block;
border: 1px solid blue;
text-decoration: underline;
color: blue;
}

http://www.google.com/images/logo.gif"; width="300"  
height="150">fallback

http://hardocp.com/";>test
src="http://www.google.com/images/logo.gif";>fallback


However, -o-replace seems broken, -o-link doesn't always work right,  
attr() doesn't always work right, you can't specify the type/unit of what  
attr() returns (although I think there's a spec for that that no vendor  
follows) and using -o-link with -o-replace probably wouldn't work if  
-o-replace worked right. You can try in Opera 8.x maybe. It might work  
better there.


So, the support is all broken and limited. However, I've always loved the  
idea of it and even like that it's done via CSS. Whether it's more  
semantic to use  inside something and  around something or not  
doesn't really matter to me.


So, I think the end result of having all elements support @src and @href  
(not necessarily with css like above) would be cool. Yet, vendor devs have  
said that it'd be a pain and or annoying to implement, so...


I don't feel super strongly about it though. I just think it'd be  
nice/cool.


--
Michael

Re: [whatwg] localStorage feedback

[Jeremy Orlow]

On Tue, Nov 3, 2009 at 9:51 AM, Darin Fisher  wrote:

> On Mon, Nov 2, 2009 at 3:46 PM, Robert O'Callahan wrote:
>
>> On Tue, Nov 3, 2009 at 6:36 AM, Darin Fisher  wrote:
>>
>>> 1a) Given a page (domain A) containing an iframe (domain B), have the
>>> outer page navigate the inner frame to "about:blank".  This navigation
>>> completes synchronously, and the unload handler for the iframe runs before
>>> the navigation request completes.  This is true of all browsers.
>>>
>>> 1b) Suppose the inner page has a pending XMLHttpRequest when the outer
>>> frame navigates the inner frame.  The XHR's onabort handler would run before
>>> the navigation to "about:blank" completes.
>>>
>>
>> These are really the same problem: synchronous cross-domain about:blank
>> navigation. If navigation to about:blank has to be synchronous, then I guess
>> it needs to drop the lock, at least in the cross-domain case.
>>
>
> That's correct.  My point is simple:  Here is another case where nesting
> can happen that hadn't been foreseen.  Trying to foresee all such issues is
> difficult.
>
> Will we just keep amending the spec each time we find such a possible case?
>
> I think it is far saner to say that any nesting leads to unlocking the
> storage mutex.  The spec can then list cases where this nesting might occur.
>
>
>
>>
>> 2) Set a break point in the Mozilla JS debugger.  This runs a nested event
>>> loop each time you single step so that it can drive the rest of the browser
>>> UI.
>>>
>>> 3) Install a Firefox extension that runs a nested event loop in response
>>> to an event generated by content.  I debugged many Firefox crashes resulting
>>> from extensions that do this kind of thing for various reasons.
>>>
>>
>> These are internal Mozilla issues and should not be allowed to influence
>> the design of the Web platform. They'll probably change for multi-process
>> anyway.
>>
>
> OK, but my point is that the spec should afford implementors with the
> ability to unlock the storage mutex at other times for reasons not mentioned
> in the spec.
>

If we do this, we need to re-visit ways that scripts can tell whether the
lock has been dropped.  I can't remember which idea was most in favor last
time we talked about it, but a counter that increments every time
LocalStorage is unlocked sticks out in my mind.  (Scripts can check the
counter, do something that could cause unlocking, and then verify the
counter is still the same after.)  Another option that just came to mind is
to have some flag that says "throw an exception whenever there's been
a serialization violation".

Just to be clear for those following along at home: If we (Chrome) implement
the storage mutex for the next version of Chrome, it'll have to be the way
Darin's describing (mainly for schedule based reasons).  It would be nice to
eventually fix all the cases that cause unnecessary unlocking, but that's
going to take a while.

 I'm not convinced.  Look at Google Maps and street view.  Gmail uses more
>>> Flash now than it used to.
>>>
>>
>> For new features, sure. But are they reimplementing existing browser-based
>> functionality to use plugins instead?
>>
>
> I think it is sufficient to just talk in the context of new features.  A JS
> library or component grows a new feature that suddenly starts using a
> plugin.  Now, API calls that were not supposed to touch plugins start
> touching plugins, and the storage mutex gets dropped.
>
>
>
>>
>>
>>>
 What will you do for Gecko when it supports content processes?
>

 Implement the spec, I hope!
>>>
>>>
>>> It seems odd to me that this behavior was put into the spec without any
>>> implementation experience to guide it.  The only multi-process
>>> implementations that I know of do not have a storage mutex.
>>>
>>
>> Lots of things are in the spec without implementation experience. I think
>> we have time to collect more experience on this issue with multi-process
>> browsers and revise the spec in light of it.
>>
>>
> OK.  Please note my objection to the storage mutex.
>

And mine.  :-)

Re: [whatwg] elemen.onFocus instead of window.onhashcange ?

[Michael A. Puls II]

On Tue, 03 Nov 2009 15:24:13 -0500, Mike Taylor  
 wrote:





PS: Please ease on the JavaScripting on the WHATWG version of the
spec. I've got a quite old computer and Firefox freezes on me when I
visit that page too often. Is all of that needed? Or don't old UAs
matter to such an backwards compatible spec?



Are you aware of the multi-page spec (
http://www.whatwg.org/specs/web-apps/current-work/multipage/)?
The single page version will bring any browser to its knees.


Webkit browsers (Safari Win32 for example) handle the single page version  
really well even on ancient computers.


However, if you still want the single-page version (becauses it's easier  
to search) for Firefox, Opera and IE, you can use  
, which  
will make things better (although you lose some advanced features on the  
page).


--
Michael

Re: [whatwg] elemen.onFocus instead of window.onhashcange ?

[Robert O'Callahan]

On Wed, Nov 4, 2009 at 1:16 PM, Michael A. Puls II wrote:

> Webkit browsers (Safari Win32 for example) handle the single page version
> really well even on ancient computers.
>

One interesting reason for that is discussed here:
http://weblogs.mozillazine.org/bz/archives/020267.html

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Adding a src attribute to all elements

[Nils Dagsson Moskopp]

Am Tue, 03 Nov 2009 21:05:26 -0500
schrieb Curtiss Grymala :

> I would like to propose that a src attribute be added to the spec for
> all HTML elements. The content of the file referenced in the src
> attribute would then replace the contents of the element that contains
> the src attribute. The src attribute would then be interpreted
> differently, depending on the type of file referenced in that src
> attribute.

A perfectly good way to go confuse people, if you ask me.

> For instance, if I create a level 1 header that looks like:
> This is a header
> The text "This is a header" would be replaced with the image that's
> located at /example.png. However, if /example.png returns a 404 error,
> the text would be displayed instead.

How is that different than this example ?


> If, however, I create a div that looks like:
> This is some other text
> The text content of /example.txt would replace the text "This is some
> other text" within the div that I created. Again, though,
> if /example.txt returned a 404 error, then "This is some other text"
> would show up inside the div instead.

 and  elements are fine too.

> The contents of the file referenced in the src attribute would need to
> be parsed and rendered prior to replacing the initial content of the
> element. For instance, if I reference a PHP file in the src
> attribute, I would expect the PHP to be parsed before it shows up in
> my document.

I would suggest learning the semantics of the  element.
Also, PHP is server side, HTML is client side.

> I'm not sure if this is at all feasible, but I personally think it
> would be a great addition to the spec. Thank you.

What would be the use case for this ?


-- 
Nils Dagsson Moskopp // erlehmann



signature.asc
Description: PGP signature

Re: [whatwg] Adding a src attribute to all elements

[Remco]

On Wed, Nov 4, 2009 at 03:05, Curtiss Grymala  wrote:
> I would like to propose that a src attribute be added to the spec for
> all HTML elements. The content of the file referenced in the src
> attribute would then replace the contents of the element that contains
> the src attribute. The src attribute would then be interpreted
> differently, depending on the type of file referenced in that src
> attribute.

I tried to do something similar: I tried to get the alt attribute on
all elements with external content. That would have made the HTML
specification more consistent. But I think we have to accept that HTML
is not a beautiful streamlined well-designed language. Everything you
add to the specification needs to be implemented by all browsers. They
all need to see the merit of it. Can you think of a good use case for
this? What problem would it solve? If you can convince people that
they have a problem which you solve, then you're in business.

> For instance, if I reference a PHP file in the src attribute, I
> would expect the PHP to be parsed before it shows up in my document.

Minor nitpick: HTML does not influence that. A PHP file is translated
into HTML on the server and then that HTML is served to the browser.
The browser always only sees HTML. The .php extension has no meaning.
It could just as well be .html or .foobar.

-- 
Remco

Re: [whatwg] Sectioning

[Wesley Walser]

I had to read it several times to get it as well.

"...regardless of what implied sections other headings may have created."

That is the part that answers the questions I believe. Yes, any
element that starts an explicit section is *not* a subsection of
nearest implicit sections. Also, any element that create an explicit
section, ends any implicit sections on it's same level.

Thanks,
Wes

On Mon, Nov 2, 2009 at 6:13 PM, Elizabeth Castro  wrote:
> In 4.4.11, it says
>
> Sectioning content elements are always considered subsections of their
> nearest ancestor element of sectioning content, regardless of what implied
> sections other headings may have created.
>
> Does that line mean that a section element is *not* a subsection of the
> nearest implied section?
> So, if there is no other explicit sectioning content, as in the example
> given, then what would the section element be a subsection of?
> I don't get why Thud ends up on an equal level as Quux and Bar. It seems
> like as a section under h2 it should be a subsection of that Quux h2, just
> as the implied Bar section is a subsection of the implied Foo section.
> thanks,
> Liz
>
>

Re: [whatwg] elemen.onFocus instead of window.onhashcange ?

[Michael A. Puls II]

On Tue, 03 Nov 2009 19:26:58 -0500, Robert O'Callahan  
 wrote:


On Wed, Nov 4, 2009 at 1:16 PM, Michael A. Puls II  
wrote:


Webkit browsers (Safari Win32 for example) handle the single page  
version

really well even on ancient computers.



One interesting reason for that is discussed here:
http://weblogs.mozillazine.org/bz/archives/020267.html


Interesting. Thanks.

--
Michael

Re: [whatwg] elemen.onFocus instead of window.onhashcange ?

[Mike Taylor]

>
>
> PS: Please ease on the JavaScripting on the WHATWG version of the
> spec. I've got a quite old computer and Firefox freezes on me when I
> visit that page too often. Is all of that needed? Or don't old UAs
> matter to such an backwards compatible spec?
>
>
Are you aware of the multi-page spec (
http://www.whatwg.org/specs/web-apps/current-work/multipage/)?
The single page version will bring any browser to its knees.

Cheers,
Mike

Re: [whatwg] localStorage feedback

[Robert O'Callahan]

On Wed, Nov 4, 2009 at 6:51 AM, Darin Fisher  wrote:

> That's correct.  My point is simple:  Here is another case where nesting
> can happen that hadn't been foreseen.  Trying to foresee all such issues is
> difficult.
>

Yes.

Will we just keep amending the spec each time we find such a possible case?
>

I would.


> OK, but my point is that the spec should afford implementors with the
> ability to unlock the storage mutex at other times for reasons not mentioned
> in the spec.
>

I disagree, because this gives implementors freedom to drop the mutex in
situations that might really just be fixable implementation bugs. I think
our positions are clear now so we'll just have to agree to disagree.


>
>>
>> I'm not convinced.  Look at Google Maps and street view.  Gmail uses more
>>> Flash now than it used to.
>>>
>>
>> For new features, sure. But are they reimplementing existing browser-based
>> functionality to use plugins instead?
>>
>
> I think it is sufficient to just talk in the context of new features.  A JS
> library or component grows a new feature that suddenly starts using a
> plugin.  Now, API calls that were not supposed to touch plugins start
> touching plugins, and the storage mutex gets dropped.
>

That only matters if they start using the new feature in the middle of a
localStorage "transaction". That seems possible, but unlikely, to me.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] localStorage feedback

[Darin Fisher]

On Mon, Nov 2, 2009 at 3:46 PM, Robert O'Callahan wrote:

> On Tue, Nov 3, 2009 at 6:36 AM, Darin Fisher  wrote:
>
>> 1a) Given a page (domain A) containing an iframe (domain B), have the
>> outer page navigate the inner frame to "about:blank".  This navigation
>> completes synchronously, and the unload handler for the iframe runs before
>> the navigation request completes.  This is true of all browsers.
>>
>> 1b) Suppose the inner page has a pending XMLHttpRequest when the outer
>> frame navigates the inner frame.  The XHR's onabort handler would run before
>> the navigation to "about:blank" completes.
>>
>
> These are really the same problem: synchronous cross-domain about:blank
> navigation. If navigation to about:blank has to be synchronous, then I guess
> it needs to drop the lock, at least in the cross-domain case.
>

That's correct.  My point is simple:  Here is another case where nesting can
happen that hadn't been foreseen.  Trying to foresee all such issues is
difficult.

Will we just keep amending the spec each time we find such a possible case?

I think it is far saner to say that any nesting leads to unlocking the
storage mutex.  The spec can then list cases where this nesting might occur.



>
> 2) Set a break point in the Mozilla JS debugger.  This runs a nested event
>> loop each time you single step so that it can drive the rest of the browser
>> UI.
>>
>> 3) Install a Firefox extension that runs a nested event loop in response
>> to an event generated by content.  I debugged many Firefox crashes resulting
>> from extensions that do this kind of thing for various reasons.
>>
>
> These are internal Mozilla issues and should not be allowed to influence
> the design of the Web platform. They'll probably change for multi-process
> anyway.
>

OK, but my point is that the spec should afford implementors with the
ability to unlock the storage mutex at other times for reasons not mentioned
in the spec.



>
> I'm not convinced.  Look at Google Maps and street view.  Gmail uses more
>> Flash now than it used to.
>>
>
> For new features, sure. But are they reimplementing existing browser-based
> functionality to use plugins instead?
>

I think it is sufficient to just talk in the context of new features.  A JS
library or component grows a new feature that suddenly starts using a
plugin.  Now, API calls that were not supposed to touch plugins start
touching plugins, and the storage mutex gets dropped.



>
>
>>
>>> What will you do for Gecko when it supports content processes?

>>>
>>> Implement the spec, I hope!
>>
>>
>> It seems odd to me that this behavior was put into the spec without any
>> implementation experience to guide it.  The only multi-process
>> implementations that I know of do not have a storage mutex.
>>
>
> Lots of things are in the spec without implementation experience. I think
> we have time to collect more experience on this issue with multi-process
> browsers and revise the spec in light of it.
>
>
OK.  Please note my objection to the storage mutex.

-Darin

[whatwg] should async scripts block the document's load event?

[Brian Kuhn]

In section 
4.3.1,
it says:

*Fetching an external script must delay the load event of the element's
document until the task that is queued by the networking task source once
the resource has been fetched (defined above) has been run.*

Has any thought been put into changing this for async scripts?  It seems
like it might be worthwhile to allow window.onload to fire while an async
script is still downloading if everything else is done.

Thanks,
Brian

[whatwg] Adding a src attribute to all elements

[Curtiss Grymala]

I would like to propose that a src attribute be added to the spec for
all HTML elements. The content of the file referenced in the src
attribute would then replace the contents of the element that contains
the src attribute. The src attribute would then be interpreted
differently, depending on the type of file referenced in that src
attribute.

For instance, if I create a level 1 header that looks like:
This is a header
The text "This is a header" would be replaced with the image that's
located at /example.png. However, if /example.png returns a 404 error,
the text would be displayed instead.

If, however, I create a div that looks like:
This is some other text
The text content of /example.txt would replace the text "This is some
other text" within the div that I created. Again, though,
if /example.txt returned a 404 error, then "This is some other text"
would show up inside the div instead.

The contents of the file referenced in the src attribute would need to
be parsed and rendered prior to replacing the initial content of the
element. For instance, if I reference a PHP file in the src attribute, I
would expect the PHP to be parsed before it shows up in my document.

I'm not sure if this is at all feasible, but I personally think it would
be a great addition to the spec. Thank you.




Curtiss Grymala
curt...@ten-321.com

[whatwg] elemen.onFocus instead of window.onhashcange ?

[Bjartur Thorlacius]

Wouldn't it make more sense to fire a focus event on a element whose
id is that of the new hash instead of firing hashchange on the whole
window? In most cases script authors will check the hash against a few
options and then act upon with actions such as loading a new body (or
div).

It would make sense to have the new elements in the HTML but hidden
(or out of view, but scrollable to -- though that's hard to implement)
and when the focus is thrown on the element it's scrollIntoView()d.
Maybe click or some new 'scrolledTo' event might be used instead of
focus, I don't know, but my point is the event should fire on the
element not window and it would be best to do so using an already
supported event.

Importantly this would encourage authors to use real HTML elements as
targets for their #references so UAs which don't support HTML 5
scripting interfaces and/or CSS will render all the content (though
likely some of it'll be out of the screen or not-yet rendered) but
when a user follows a link to it it'll simply scrollIntoView(). This
won't always be exactly what supposed but often close enough.

But then the scrollIntoView function definition should make clear that
non-visual UAs should also support the top argument, by only rendering
the referenced element when applicable (scrollIntoView(false)).

BTW: What happens when scrollIntoView is callod on hidden element? Or
when it's invisible because of styling?

PS: Please ease on the JavaScripting on the WHATWG version of the
spec. I've got a quite old computer and Firefox freezes on me when I
visit that page too often. Is all of that needed? Or don't old UAs
matter to such an backwards compatible spec?

--- Switch over to
Linux today --
http://www.linux.org

[whatwg] Web Workers: "SyntaxError exception"?

[Simon Pieters]

Web Workers says

"If it failed to parse, then throw a SyntaxError exception and abort all  
these steps."


Shouldn't that be SYNTAX_ERR exception?

--
Simon Pieters
Opera Software

Re: [whatwg] : A 3D Equivalent to

[Brian Blakely]

Hi Simon,

These concerns are a part of this proposal, but if we collaborate without 
dissent, a file format can be chosen/devised, and browser vendors will 
implement the spec over time, and find different solutions to the same end, I 
am sure.

I see it as a case of the chicken or the egg.  If all these perpheral 
technologies existed, we likely would not be having this discussion because it 
would be a non-issue.

Mapping content onto the 3D media is a feature I have thought about also and do 
need desperately in my design work.  However, that is not appropriate for HTML 
to handle.

You'll probably find it in CSS, something to the tune of 'div { map-model: 
url(sphere.xml) stretch etc etc }' and associated properties.

Though this is a bit tangential to the goal of this proposal, a definition 
language for 3D models could define faces which are content mappable.  Speaking 
totally of-the-cuff for the sake of clarity:



..and in CSS:

map-model: url(cube.xml) content-face stretch etc etc;

-Brian

Simon Fraser wrote:

On Nov 2, 2009, at 4:26 PM, Brian Blakely wrote:



> * Though it does not have properties for clipping, Webkit's proposed

> implementation of 3D CSS does have them for perspective.  Clipping,

> lighting, texture stretching and additional considerations could also

> be a part of that spec, but those are discussions for the CSS WG.

>

> Without a 3D media element, none of that work can be done.



Implementing your proposal would require that the model and surrounding

CSS-transformed content be implemented via the same 3D engine, sharing

a common coordinate system. That vastly increases the burden placed on

an implementor of 3D transforms: suddenly wafers in space are non longer

sufficient, and you need a new engine with support for all the features

required by your  content (which also needs to be specified  

somewhere).

You can't just glue a 3D-rendered model into an environment with  

CSS-3D-transformed

HTML elements and expect them to share a common 3D space.



> * This proposal of a model  can be considered a direct 3D analog to a

> PNG, and its height and width could certainly be modified in the X-Y

> axes on which 2D elements live, affecting document flow in that

> fashion.



A 3D analog for  is a fine goal, but the primary issue is that  

there is

no 3D file format which is accepted as a standard for this kind of  

use. Even

if there were, the analogy breaks down because 3D is structured data;  

the author

wants to be able to address certain objects in the 3D scene in order to

animate them, or do click handling on them, or whatever. There is much  

more

complexity here than there is with images. In this sense,  is  

as much

a black box for 3D as WebGL on a  is.



A further issue with this proposal is that it doesn't address another  

request,

which is to integrate HTML content into a true 3D scene (e.g. a 
  

mapped

onto a sphere, with operational hit testing etc).



> * Webkit's implementation of CSS does not remove 3D-ified elements

> from the document flow, the perspective of that flow is merely changed

> only for the affected elements.  3D and 2D elements can exist

> side-by-side that way as well.



Simon

Re: [whatwg] focus change inside keypress event handler

[Michael A. Puls II]

On Tue, 03 Nov 2009 03:26:05 -0500, Michael A. Puls II  
 wrote:


On Thu, 29 Oct 2009 21:58:29 -0400, Michael A. Puls II  
 wrote:


I'll put together a new description with the changes to see if sounds  
good.


O.K., this description might be better and sounds more like what Firefox  
does for compat with the net:


---
Fire 'keydown' first.

The default action for 'keydown' is to set the acceptKeypress flag to  
true. Using preventDefault() (either explicitly or implicitly through  
return false) prevents the default action and results in the  
acceptKeypress flag remaining false.


Changing the focus from one object to another inside the 'keydown'  
handler changes the current Context Object (what the action will be  
performed on) for the following 'keypress' handler.


After the 'keydown' handler runs, fire 'keypress'.

The default action for 'keypress' is to allow the keypress if the  
acceptKeypress flag is true.


If acceptKeypress is not true or if preventDefault() is called in the  
'keypress' handler (either explicitly or implicitly through return  
false), then the keypress is not allowed.


If the keypress is allowed then perform the action on the current  
Context Object. The action could be text insertion, text deletion,  
scrolling etc.


If the keypress is not allowed, then do not perform the action unless  
the UA does not allow preventing the action, which in that case, perform  
the action.


Note that a focus change inside a 'keypress' handler does not change the  
current Context Object for the keypress.


If the a key is being held down and Repeat Processing is supported,  
process the above over and over. (e.g. keydown -> keyup -> keydown ->  
keyup)


When the key is finally released, fire 'keyup'.

However, note that if alert(), confirm() or prompt() is used inside a  
'keydown' handler and or inside a 'keypress' handler, whether 'keyup'  
fires varies between implementations.


Also note that alert(), confirm(), prompt(), setTimeout and  
setInterval() inside the  'keydown' , 'keypress' and 'keyup' handlers  
may result in some code inside the handlers running in a different order  
than 'keydown' -> 'keypress' -> 'keyup'.

---

That's how Firefox appears to work, in my words, from the outside  
looking in.


I should also note that in the 'keydown' handler, if a focus change  
happens *after* an alert(), the focus change will not change the context  
for 'keypress' as 'keypress' will have already fired before the focus  
change happens, which probably makes my "After the 'keydown' handler runs,  
fire 'keypress'" part not entire accurate as far as "After" goes.


--
Michael

Re: [whatwg] WebStandrd for theme

[narendra sisodiya]

On Tue, Nov 3, 2009 at 2:25 PM, Markus Ernst  wrote:
> narendra sisodiya schrieb:
>>
>> On Mon, Nov 2, 2009 at 12:43 PM, Nikita Popov  wrote:
>>>
>>> narendra sisodiya schrieb:

 Many blogging site like posterous has theme editor for their
 blog/website. It is a xml file looks more like html. Following file
 was a long file which I have edited and deleted the unnecessary
 content. I think this is a non-standard way to design theme. Do we
 have any standard to such requirement ? OR we do not need any standard
 at all for such requirement.

 PS: I have searched on FBML too. Google says, It is a propri. standard
 of facebook.
>>>
>>> In the document you provided I couldn't find any tag using the
>>> fb-namespace.
>>
>> The deleted content was having fb markups, My concern was more on
>> {{something}} type of things. To me it looks highly non-standard.
>
> Yes. Re-read the next part of Nikitas Answer:
>
>>> All the other things, like {something}, are a typical method to mark up
>>> things to be inserted in Templates. They are processed by a templating
>>> engine. And I really do think that things like this don't belong to HTML,
>>> they are many templating systems, many PHP developers have their own (as
>>> I
>>> do) using markup that's convenient for them.
>
> This means that the {something} type of things are processed by a template
> application on the web server; they will typically be replaced by the
> appropriate HTML output, before the code is sent to the client (your
> browser). Check the source code in the browser to verify this. There is no
> standard for server-side template systems; HTML covers the client side.
Thanks , I got my answer.
Sorry for little noice.

Re: [whatwg] WebStandrd for theme

[Markus Ernst]

narendra sisodiya schrieb:

On Mon, Nov 2, 2009 at 12:43 PM, Nikita Popov  wrote:

narendra sisodiya schrieb:

Many blogging site like posterous has theme editor for their
blog/website. It is a xml file looks more like html. Following file
was a long file which I have edited and deleted the unnecessary
content. I think this is a non-standard way to design theme. Do we
have any standard to such requirement ? OR we do not need any standard
at all for such requirement.

PS: I have searched on FBML too. Google says, It is a propri. standard
of facebook.

In the document you provided I couldn't find any tag using the fb-namespace.

The deleted content was having fb markups, My concern was more on
{{something}} type of things. To me it looks highly non-standard.


Yes. Re-read the next part of Nikitas Answer:


All the other things, like {something}, are a typical method to mark up
things to be inserted in Templates. They are processed by a templating
engine. And I really do think that things like this don't belong to HTML,
they are many templating systems, many PHP developers have their own (as I
do) using markup that's convenient for them.


This means that the {something} type of things are processed by a 
template application on the web server; they will typically be replaced 
by the appropriate HTML output, before the code is sent to the client 
(your browser). Check the source code in the browser to verify this. 
There is no standard for server-side template systems; HTML covers the 
client side.

Re: [whatwg] focus change inside keypress event handler

[Michael A. Puls II]

On Thu, 29 Oct 2009 21:58:29 -0400, Michael A. Puls II  
 wrote:


I'll put together a new description with the changes to see if sounds  
good.


O.K., this description might be better and sounds more like what Firefox  
does for compat with the net:


---
Fire 'keydown' first.

The default action for 'keydown' is to set the acceptKeypress flag to  
true. Using preventDefault() (either explicitly or implicitly through  
return false) prevents the default action and results in the  
acceptKeypress flag remaining false.


Changing the focus from one object to another inside the 'keydown' handler  
changes the current Context Object (what the action will be performed on)  
for the following 'keypress' handler.


After the 'keydown' handler runs, fire 'keypress'.

The default action for 'keypress' is to allow the keypress if the  
acceptKeypress flag is true.


If acceptKeypress is not true or if preventDefault() is called in the  
'keypress' handler (either explicitly or implicitly through return false),  
then the keypress is not allowed.


If the keypress is allowed then perform the action on the current Context  
Object. The action could be text insertion, text deletion, scrolling etc.


If the keypress is not allowed, then do not perform the action unless the  
UA does not allow preventing the action, which in that case, perform the  
action.


Note that a focus change inside a 'keypress' handler does not change the  
current Context Object for the keypress.


If the a key is being held down and Repeat Processing is supported,  
process the above over and over. (e.g. keydown -> keyup -> keydown ->  
keyup)


When the key is finally released, fire 'keyup'.

However, note that if alert(), confirm() or prompt() is used inside a  
'keydown' handler and or inside a 'keypress' handler, whether 'keyup'  
fires varies between implementations.


Also note that alert(), confirm(), prompt(), setTimeout and setInterval()  
inside the  'keydown' , 'keypress' and 'keyup' handlers may result in some  
code inside the handlers running in a different order than 'keydown' ->  
'keypress' -> 'keyup'.

---

That's how Firefox appears to work, in my words, from the outside looking  
in.


Again though, even if that's not right, I still want the spec to go into  
details like that.


--
Michael