[whatwg] whatwg Digest, Vol 74, Issue 53
Saurabh Jain
saurabh at skjworld.com
Sat May 22 00:44:10 PDT 2010
Hi,
Image Sprite support in any form is much needed. Also certain basic
operations like collisions on image parts is also needed for certain cases.
Saurabh Jain
Director
SKJ Technologies Private Limited
http://www.skjworld.com
Author : Mobile Phone Programming using Java ME (J2ME)
http://library.skjworld.com/mobile-technology/java/java-me
On Fri, May 21, 2010 at 11:22 PM, <whatwg-request at lists.whatwg.org> wrote:
> Send whatwg mailing list submissions to
> whatwg at lists.whatwg.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org
> or, via email, send a message with subject or body 'help' to
> whatwg-request at lists.whatwg.org
>
> You can reach the person managing the list at
> whatwg-owner at lists.whatwg.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of whatwg digest..."
>
>
> Today's Topics:
>
> 1. <device> element, streams and peer-to-peer connections
> (Nicklas Sandgren)
> 2. Re: <device> element, streams and peer-to-peer connections
> (Anne van Kesteren)
> 3. WebSocket: host in server's handshake (Simon Pieters)
> 4. Re: Java language bindings for HTML5 (Boris Zbarsky)
> 5. Built-in image sprite support in HTML5 (David Weitzman)
> 6. Re: Built-in image sprite support in HTML5 (Ashley Sheridan)
> 7. Re: Built-in image sprite support in HTML5 (Tab Atkins Jr.)
> 8. Re: Should scripts and plugins in contenteditable content be
> enabled or disabled? (Perry Smith)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 21 May 2010 10:20:00 +0200
> From: Nicklas Sandgren <nicklas.sandgren at ericsson.com>
> To: "whatwg at whatwg.org" <whatwg at whatwg.org>
> Subject: [whatwg] <device> element, streams and peer-to-peer
> connections
> Message-ID:
> <
> 0F407DE9946A304F81F5C37C1DB6002A3C0D10EE at ESESSCMS0359.eemea.ericsson.se>
>
> Content-Type: text/plain; charset="us-ascii"
>
> 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.
>
> 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?
>
> 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.
>
> 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.
>
> --Nicklas Sandgren
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100521/54428374/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 21 May 2010 10:29:49 +0200
> From: "Anne van Kesteren" <annevk at opera.com>
> To: "whatwg at whatwg.org" <whatwg at whatwg.org>, "Nicklas Sandgren"
> <nicklas.sandgren at ericsson.com>
> Subject: Re: [whatwg] <device> element, streams and peer-to-peer
> connections
> Message-ID: <op.vc1q7jxd64w2qv at annevk-t60>
> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
>
> On Fri, 21 May 2010 10:20:00 +0200, Nicklas Sandgren
> <nicklas.sandgren at ericsson.com> wrote:
> > 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?
>
> Last I checked the hope is that the protocol problem will "go away". So
> far it seems that is unlikely. :-)
>
>
> > 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.
> >
> > 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.
>
> I'm not really sure how this is an alternative approach. It would just be
> leaving peer-to-messaging out... Streaming video via WebSocket is
> something we definitely want to enable in due course, irrespective of
> whether peer-to-peer messaging comes to fruition.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 21 May 2010 11:33:55 +0200
> From: "Simon Pieters" <simonp at opera.com>
> To: "whatwg at lists.whatwg.org" <whatwg at lists.whatwg.org>
> Subject: [whatwg] WebSocket: host in server's handshake
> Message-ID: <op.vc1t6tc9idj3kv at simon-pieterss-macbook.local>
> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
>
> WebSocket Sending the server's opening handshake, step 2:
>
> [[
> Establish the following information:
> host
> The host name or IP address of the WebSocket server, as it is to be
> addressed by clients. The host name must be punycode-encoded if necessary.
> If the server can respond to requests to multiple hosts (e.g. in a virtual
> hosting environment), then the value should be derived from the client's
> handshake, specifically from the "Host" field.
> ]]
>
> This should say that the host is expected to be lowercase for comparison
> purposes with the value of the Host field.
>
> --
> Simon Pieters
> Opera Software
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 21 May 2010 08:09:11 -0400
> From: Boris Zbarsky <bzbarsky at MIT.EDU>
> To: whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Java language bindings for HTML5
> Message-ID: <4BF677E7.6050703 at mit.edu>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 5/21/10 1:34 AM, Shiki Okasaka wrote:
> > * backward binary compatibility: the application programs developed
> > with the former SDKs should run with browsers as long as browsers
> > retain the required features for ECMAScript.
>
> Gecko has this now for DOM interfaces, mostly. It's a noticeable
> performance and memory penalty, especially as features need to be added,
> due to the way it's implemented right now on top of C++ vtables. As
> Benjamin mentioned, we will most likely stop doing this by default for
> the core DOM interfaces. Someone could still provide a stable ABI in
> some form of C++ binding, but it's not clear to me that we plan to do
> that ourselves. Patches accepted, probably.
>
> -Boris
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 21 May 2010 10:12:50 -0700
> From: David Weitzman <dweitzman at gmail.com>
> To: whatwg at lists.whatwg.org
> Subject: [whatwg] Built-in image sprite support in HTML5
> Message-ID:
> <AANLkTikmrUmpsdUN4Zq-NnB4WFfm65_v2iMhpIfd1SI6 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> There are various approaches to using image sprites with HTML and CSS,
> but at the end of the day they are all essentially hacks. A solution
> that would be simpler than any existing approach would be to introduce
> new attributes for <img> to specify x and y offsets and clipping on
> images. With that you would get simpler markup for sprites and better
> accessibility.
>
> One downside of this approach is that with background image sprites
> you can have a CSS class that abstracts away the name of the sprite
> image. With <img> tags you would have to specify the URL and
> height/width individually on every sprited image.
>
> Thoughts?
>
> - David
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 21 May 2010 18:11:12 +0100
> From: Ashley Sheridan <ash at ashleysheridan.co.uk>
> To: David Weitzman <dweitzman at gmail.com>
> Cc: whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Built-in image sprite support in HTML5
> Message-ID: <1274461872.2202.157.camel at localhost>
> Content-Type: text/plain; charset="us-ascii"
>
> On Fri, 2010-05-21 at 10:12 -0700, David Weitzman wrote:
>
> > There are various approaches to using image sprites with HTML and CSS,
> > but at the end of the day they are all essentially hacks. A solution
> > that would be simpler than any existing approach would be to introduce
> > new attributes for <img> to specify x and y offsets and clipping on
> > images. With that you would get simpler markup for sprites and better
> > accessibility.
> >
> > One downside of this approach is that with background image sprites
> > you can have a CSS class that abstracts away the name of the sprite
> > image. With <img> tags you would have to specify the URL and
> > height/width individually on every sprited image.
> >
> > Thoughts?
> >
> > - David
>
>
> It does seem like a good idea, because it does make sure that the
> sprites are accessible, which they really aren't at the moment.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100521/d80993ff/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 7
> Date: Fri, 21 May 2010 10:23:55 -0700
> From: "Tab Atkins Jr." <jackalmage at gmail.com>
> To: David Weitzman <dweitzman at gmail.com>
> Cc: whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Built-in image sprite support in HTML5
> Message-ID:
> <AANLkTilWEbME7LDk79YvsVAeqGZnMwFnPoxQUvdDOg4E at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, May 21, 2010 at 10:12 AM, David Weitzman <dweitzman at gmail.com>
> wrote:
> > There are various approaches to using image sprites with HTML and CSS,
> > but at the end of the day they are all essentially hacks. A solution
> > that would be simpler than any existing approach would be to introduce
> > new attributes for <img> to specify x and y offsets and clipping on
> > images. With that you would get simpler markup for sprites and better
> > accessibility.
> >
> > One downside of this approach is that with background image sprites
> > you can have a CSS class that abstracts away the name of the sprite
> > image. With <img> tags you would have to specify the URL and
> > height/width individually on every sprited image.
>
> Agreed on all points about the current spriting solutions being hacks.
>
> This problem is already being addressed on multiple fronts, though
> they are all still somewhat theoretical at the moment.
>
> The Media Fragments WG has a draft spec out for, well, Media
> Fragments, which let you specify which section of an image you want
> right in the url. The browser should then automatically cut it out
> and serve just the sprite you want.
>
> The CSSWG has a few proposals in a very rough state, detailed in the
> CSS Images spec.
>
> Finally, there have been proposals for removing the need to sprite
> altogether, by allowing authors to send a bunch of resources packed
> into a single compressed archive, and just addressing individual files
> inside of it.
>
> So, while none of these are exactly imminent, there is activity in
> this sphere already occuring.
>
> ~TJ
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 21 May 2010 12:46:35 -0500
> From: Perry Smith <pedzsan at gmail.com>
> To: Collin Jackson <w3c at collinjackson.com>
> Cc: WHATWG <whatwg at lists.whatwg.org>, Ojan Vafai <ojan at chromium.org>,
> Adam Barth <w3c at adambarth.com>, Simon Pieters <simonp at opera.com>,
> robert at ocallahan.org
> Subject: Re: [whatwg] Should scripts and plugins in contenteditable
> content be enabled or disabled?
> Message-ID: <5585B4EB-6359-4504-8F74-9D391B7151CE at gmail.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
> On May 19, 2010, at 8:14 PM, Collin Jackson wrote:
>
> > On Wed, May 19, 2010 at 4:57 PM, Adam Barth <w3c at adambarth.com> wrote:
> > Virtually none of the JavaScript framebusting scripts used by web
> > sites are effective.
> >
> > 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.
> >
> > http://w2spconf.com/2010/papers/p27.pdf
> 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.
>
> Perry
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100521/ae5df3d2/attachment.htm
> >
>
> ------------------------------
>
> _______________________________________________
> whatwg mailing list
> whatwg at lists.whatwg.org
> http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org
>
>
> End of whatwg Digest, Vol 74, Issue 53
> **************************************
>
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100522/6d019041/attachment-0002.htm>
More information about the whatwg
mailing list