Hi,<div><br></div><div>Image Sprite support in any form is much needed. Also certain basic operations like collisions on image parts is also needed for certain cases.</div><div><br></div><div>Saurabh Jain<br>Director<br>SKJ Technologies Private Limited<br>
<a href="http://www.skjworld.com">http://www.skjworld.com</a><br>Author : Mobile Phone Programming using Java ME (J2ME)<br><a href="http://library.skjworld.com/mobile-technology/java/java-me">http://library.skjworld.com/mobile-technology/java/java-me</a><br>
<br><div class="gmail_quote">On Fri, May 21, 2010 at 11:22 PM, <span dir="ltr"><<a href="mailto:whatwg-request@lists.whatwg.org">whatwg-request@lists.whatwg.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Send whatwg mailing list submissions to<br>
<a href="mailto:whatwg@lists.whatwg.org">whatwg@lists.whatwg.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org" target="_blank">http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:whatwg-request@lists.whatwg.org">whatwg-request@lists.whatwg.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:whatwg-owner@lists.whatwg.org">whatwg-owner@lists.whatwg.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of whatwg digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. <device> element, streams and peer-to-peer connections<br>
(Nicklas Sandgren)<br>
2. Re: <device> element, streams and peer-to-peer connections<br>
(Anne van Kesteren)<br>
3. WebSocket: host in server's handshake (Simon Pieters)<br>
4. Re: Java language bindings for HTML5 (Boris Zbarsky)<br>
5. Built-in image sprite support in HTML5 (David Weitzman)<br>
6. Re: Built-in image sprite support in HTML5 (Ashley Sheridan)<br>
7. Re: Built-in image sprite support in HTML5 (Tab Atkins Jr.)<br>
8. Re: Should scripts and plugins in contenteditable content be<br>
enabled or disabled? (Perry Smith)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 21 May 2010 10:20:00 +0200<br>
From: Nicklas Sandgren <<a href="mailto:nicklas.sandgren@ericsson.com">nicklas.sandgren@ericsson.com</a>><br>
To: "<a href="mailto:whatwg@whatwg.org">whatwg@whatwg.org</a>" <<a href="mailto:whatwg@whatwg.org">whatwg@whatwg.org</a>><br>
Subject: [whatwg] <device> element, streams and peer-to-peer<br>
connections<br>
Message-ID:<br>
<<a href="mailto:0F407DE9946A304F81F5C37C1DB6002A3C0D10EE@ESESSCMS0359.eemea.ericsson.se">0F407DE9946A304F81F5C37C1DB6002A3C0D10EE@ESESSCMS0359.eemea.ericsson.se</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Looking at the latest draft, section 4.11.6 contains a proposal for the <device> element as discussed quite extensively on the W3C DAP list. In addition there is a Stream API and a sub-section on peer-to-peer connections.<br>
<br>
As mentioned in the draft, the peer-to-peer API must rely on underlying protocols/mechanisms to establish the connections and to transport the streams. What are the thoughts regarding these protocols, and has there been any discussion around this topic?<br>
<br>
An alternative approach could be to define APIs for managing streams only, and leave session set up as well as additional functionality (file, text, image share) to the application using the means already available such as XMLHttpRequest and WebSocket. The session set up would in this scenario not rely on a third party server, but rather be handled by the server that serves the current web application. This would remove the need for agreeing on formats for client and server configuration strings or protocols to talk to third-party servers.<br>
<br>
You could also debate how often peer-to-peer media streams will actually work. Aren't FWs and NATs going to give problems in many cases? Maybe it would be better to design for a situation where the media always go via a server. Additional benefits are that WS could be used for media transport, and that the media could be transcoded if the codec capabilities of the clients do not match.<br>
<br>
--Nicklas Sandgren<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100521/54428374/attachment-0001.htm" target="_blank">http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100521/54428374/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 21 May 2010 10:29:49 +0200<br>
From: "Anne van Kesteren" <<a href="mailto:annevk@opera.com">annevk@opera.com</a>><br>
To: "<a href="mailto:whatwg@whatwg.org">whatwg@whatwg.org</a>" <<a href="mailto:whatwg@whatwg.org">whatwg@whatwg.org</a>>, "Nicklas Sandgren"<br>
<<a href="mailto:nicklas.sandgren@ericsson.com">nicklas.sandgren@ericsson.com</a>><br>
Subject: Re: [whatwg] <device> element, streams and peer-to-peer<br>
connections<br>
Message-ID: <op.vc1q7jxd64w2qv@annevk-t60><br>
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes<br>
<br>
On Fri, 21 May 2010 10:20:00 +0200, Nicklas Sandgren<br>
<<a href="mailto:nicklas.sandgren@ericsson.com">nicklas.sandgren@ericsson.com</a>> wrote:<br>
> As mentioned in the draft, the peer-to-peer API must rely on underlying<br>
> protocols/mechanisms to establish the connections and to transport the<br>
> streams. What are the thoughts regarding these protocols, and has there<br>
> been any discussion around this topic?<br>
<br>
Last I checked the hope is that the protocol problem will "go away". So<br>
far it seems that is unlikely. :-)<br>
<br>
<br>
> An alternative approach could be to define APIs for managing streams<br>
> only, and leave session set up as well as additional functionality<br>
> (file, text, image share) to the application using the means already<br>
> available such as XMLHttpRequest and WebSocket. The session set up would<br>
> in this scenario not rely on a third party server, but rather be handled<br>
> by the server that serves the current web application. This would remove<br>
> the need for agreeing on formats for client and server configuration<br>
> strings or protocols to talk to third-party servers.<br>
><br>
> You could also debate how often peer-to-peer media streams will actually<br>
> work. Aren't FWs and NATs going to give problems in many cases? Maybe it<br>
> would be better to design for a situation where the media always go via<br>
> a server. Additional benefits are that WS could be used for media<br>
> transport, and that the media could be transcoded if the codec<br>
> capabilities of the clients do not match.<br>
<br>
I'm not really sure how this is an alternative approach. It would just be<br>
leaving peer-to-messaging out... Streaming video via WebSocket is<br>
something we definitely want to enable in due course, irrespective of<br>
whether peer-to-peer messaging comes to fruition.<br>
<br>
<br>
--<br>
Anne van Kesteren<br>
<a href="http://annevankesteren.nl/" target="_blank">http://annevankesteren.nl/</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 21 May 2010 11:33:55 +0200<br>
From: "Simon Pieters" <<a href="mailto:simonp@opera.com">simonp@opera.com</a>><br>
To: "<a href="mailto:whatwg@lists.whatwg.org">whatwg@lists.whatwg.org</a>" <<a href="mailto:whatwg@lists.whatwg.org">whatwg@lists.whatwg.org</a>><br>
Subject: [whatwg] WebSocket: host in server's handshake<br>
Message-ID: <op.vc1t6tc9idj3kv@simon-pieterss-macbook.local><br>
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes<br>
<br>
WebSocket Sending the server's opening handshake, step 2:<br>
<br>
[[<br>
Establish the following information:<br>
host<br>
The host name or IP address of the WebSocket server, as it is to be<br>
addressed by clients. The host name must be punycode-encoded if necessary.<br>
If the server can respond to requests to multiple hosts (e.g. in a virtual<br>
hosting environment), then the value should be derived from the client's<br>
handshake, specifically from the "Host" field.<br>
]]<br>
<br>
This should say that the host is expected to be lowercase for comparison<br>
purposes with the value of the Host field.<br>
<br>
--<br>
Simon Pieters<br>
Opera Software<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Fri, 21 May 2010 08:09:11 -0400<br>
From: Boris Zbarsky <<a href="mailto:bzbarsky@MIT.EDU">bzbarsky@MIT.EDU</a>><br>
To: <a href="mailto:whatwg@lists.whatwg.org">whatwg@lists.whatwg.org</a><br>
Subject: Re: [whatwg] Java language bindings for HTML5<br>
Message-ID: <<a href="mailto:4BF677E7.6050703@mit.edu">4BF677E7.6050703@mit.edu</a>><br>
Content-Type: text/plain; charset=UTF-8; format=flowed<br>
<br>
On 5/21/10 1:34 AM, Shiki Okasaka wrote:<br>
> * backward binary compatibility: the application programs developed<br>
> with the former SDKs should run with browsers as long as browsers<br>
> retain the required features for ECMAScript.<br>
<br>
Gecko has this now for DOM interfaces, mostly. It's a noticeable<br>
performance and memory penalty, especially as features need to be added,<br>
due to the way it's implemented right now on top of C++ vtables. As<br>
Benjamin mentioned, we will most likely stop doing this by default for<br>
the core DOM interfaces. Someone could still provide a stable ABI in<br>
some form of C++ binding, but it's not clear to me that we plan to do<br>
that ourselves. Patches accepted, probably.<br>
<br>
-Boris<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Fri, 21 May 2010 10:12:50 -0700<br>
From: David Weitzman <<a href="mailto:dweitzman@gmail.com">dweitzman@gmail.com</a>><br>
To: <a href="mailto:whatwg@lists.whatwg.org">whatwg@lists.whatwg.org</a><br>
Subject: [whatwg] Built-in image sprite support in HTML5<br>
Message-ID:<br>
<<a href="mailto:AANLkTikmrUmpsdUN4Zq-NnB4WFfm65_v2iMhpIfd1SI6@mail.gmail.com">AANLkTikmrUmpsdUN4Zq-NnB4WFfm65_v2iMhpIfd1SI6@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
There are various approaches to using image sprites with HTML and CSS,<br>
but at the end of the day they are all essentially hacks. A solution<br>
that would be simpler than any existing approach would be to introduce<br>
new attributes for <img> to specify x and y offsets and clipping on<br>
images. With that you would get simpler markup for sprites and better<br>
accessibility.<br>
<br>
One downside of this approach is that with background image sprites<br>
you can have a CSS class that abstracts away the name of the sprite<br>
image. With <img> tags you would have to specify the URL and<br>
height/width individually on every sprited image.<br>
<br>
Thoughts?<br>
<br>
- David<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Fri, 21 May 2010 18:11:12 +0100<br>
From: Ashley Sheridan <<a href="mailto:ash@ashleysheridan.co.uk">ash@ashleysheridan.co.uk</a>><br>
To: David Weitzman <<a href="mailto:dweitzman@gmail.com">dweitzman@gmail.com</a>><br>
Cc: <a href="mailto:whatwg@lists.whatwg.org">whatwg@lists.whatwg.org</a><br>
Subject: Re: [whatwg] Built-in image sprite support in HTML5<br>
Message-ID: <1274461872.2202.157.camel@localhost><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
On Fri, 2010-05-21 at 10:12 -0700, David Weitzman wrote:<br>
<br>
> There are various approaches to using image sprites with HTML and CSS,<br>
> but at the end of the day they are all essentially hacks. A solution<br>
> that would be simpler than any existing approach would be to introduce<br>
> new attributes for <img> to specify x and y offsets and clipping on<br>
> images. With that you would get simpler markup for sprites and better<br>
> accessibility.<br>
><br>
> One downside of this approach is that with background image sprites<br>
> you can have a CSS class that abstracts away the name of the sprite<br>
> image. With <img> tags you would have to specify the URL and<br>
> height/width individually on every sprited image.<br>
><br>
> Thoughts?<br>
><br>
> - David<br>
<br>
<br>
It does seem like a good idea, because it does make sure that the<br>
sprites are accessible, which they really aren't at the moment.<br>
<br>
Thanks,<br>
Ash<br>
<a href="http://www.ashleysheridan.co.uk" target="_blank">http://www.ashleysheridan.co.uk</a><br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100521/d80993ff/attachment-0001.htm" target="_blank">http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100521/d80993ff/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Fri, 21 May 2010 10:23:55 -0700<br>
From: "Tab Atkins Jr." <<a href="mailto:jackalmage@gmail.com">jackalmage@gmail.com</a>><br>
To: David Weitzman <<a href="mailto:dweitzman@gmail.com">dweitzman@gmail.com</a>><br>
Cc: <a href="mailto:whatwg@lists.whatwg.org">whatwg@lists.whatwg.org</a><br>
Subject: Re: [whatwg] Built-in image sprite support in HTML5<br>
Message-ID:<br>
<<a href="mailto:AANLkTilWEbME7LDk79YvsVAeqGZnMwFnPoxQUvdDOg4E@mail.gmail.com">AANLkTilWEbME7LDk79YvsVAeqGZnMwFnPoxQUvdDOg4E@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Fri, May 21, 2010 at 10:12 AM, David Weitzman <<a href="mailto:dweitzman@gmail.com">dweitzman@gmail.com</a>> wrote:<br>
> There are various approaches to using image sprites with HTML and CSS,<br>
> but at the end of the day they are all essentially hacks. A solution<br>
> that would be simpler than any existing approach would be to introduce<br>
> new attributes for <img> to specify x and y offsets and clipping on<br>
> images. With that you would get simpler markup for sprites and better<br>
> accessibility.<br>
><br>
> One downside of this approach is that with background image sprites<br>
> you can have a CSS class that abstracts away the name of the sprite<br>
> image. With <img> tags you would have to specify the URL and<br>
> height/width individually on every sprited image.<br>
<br>
Agreed on all points about the current spriting solutions being hacks.<br>
<br>
This problem is already being addressed on multiple fronts, though<br>
they are all still somewhat theoretical at the moment.<br>
<br>
The Media Fragments WG has a draft spec out for, well, Media<br>
Fragments, which let you specify which section of an image you want<br>
right in the url. The browser should then automatically cut it out<br>
and serve just the sprite you want.<br>
<br>
The CSSWG has a few proposals in a very rough state, detailed in the<br>
CSS Images spec.<br>
<br>
Finally, there have been proposals for removing the need to sprite<br>
altogether, by allowing authors to send a bunch of resources packed<br>
into a single compressed archive, and just addressing individual files<br>
inside of it.<br>
<br>
So, while none of these are exactly imminent, there is activity in<br>
this sphere already occuring.<br>
<br>
~TJ<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Fri, 21 May 2010 12:46:35 -0500<br>
From: Perry Smith <<a href="mailto:pedzsan@gmail.com">pedzsan@gmail.com</a>><br>
To: Collin Jackson <<a href="mailto:w3c@collinjackson.com">w3c@collinjackson.com</a>><br>
Cc: WHATWG <<a href="mailto:whatwg@lists.whatwg.org">whatwg@lists.whatwg.org</a>>, Ojan Vafai <<a href="mailto:ojan@chromium.org">ojan@chromium.org</a>>,<br>
Adam Barth <<a href="mailto:w3c@adambarth.com">w3c@adambarth.com</a>>, Simon Pieters <<a href="mailto:simonp@opera.com">simonp@opera.com</a>>,<br>
<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a><br>
Subject: Re: [whatwg] Should scripts and plugins in contenteditable<br>
content be enabled or disabled?<br>
Message-ID: <<a href="mailto:5585B4EB-6359-4504-8F74-9D391B7151CE@gmail.com">5585B4EB-6359-4504-8F74-9D391B7151CE@gmail.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
<br>
On May 19, 2010, at 8:14 PM, Collin Jackson wrote:<br>
<br>
> On Wed, May 19, 2010 at 4:57 PM, Adam Barth <<a href="mailto:w3c@adambarth.com">w3c@adambarth.com</a>> wrote:<br>
> Virtually none of the JavaScript framebusting scripts used by web<br>
> sites are effective.<br>
><br>
> Yes. If anyone would like to see more evidence of this, here's a recent study of the Alexa Top 500 web sites. None of them were framebusting correctly with JavaScript.<br>
><br>
> <a href="http://w2spconf.com/2010/papers/p27.pdf" target="_blank">http://w2spconf.com/2010/papers/p27.pdf</a><br>
This probably is not the right list for this but seems like the X-FRAME-OPTIONS http header could be strengthened by having the UA send all requests from pages that have the X-FRAME-OPTIONS to also containt either the X-FRAME-OPTIONS or another tag. One weakness pointed out in the paper is that proxies can strip the header. If the server doesn't see the header come back, it would know that it got stripped out and the request needs to be questioned. I don't know if there is a way to introduced "fake" http headers into requests or not. If there is, that would need to be addressed too.<br>
<br>
Perry<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100521/ae5df3d2/attachment.htm" target="_blank">http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100521/ae5df3d2/attachment.htm</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
whatwg mailing list<br>
<a href="mailto:whatwg@lists.whatwg.org">whatwg@lists.whatwg.org</a><br>
<a href="http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org" target="_blank">http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org</a><br>
<br>
<br>
End of whatwg Digest, Vol 74, Issue 53<br>
**************************************<br>
</blockquote></div><br><br clear="all"><br>-- <br><br>
</div>