Re: [whatwg] Supporting scrollTop and scrollLeft on the Canvas element

2012-02-04 Thread Anne van Kesteren
On Tue, 31 Jan 2012 23:35:45 +0100, Charles Pritchard ch...@jumis.com  
wrote:
I'd like to see scrollTop and scrollLeft supported for the Canvas  
element. They would simply fire an onscroll event on the element, and do  
nothing else.
Many Canvas UIs use only one visible canvas layer, or otherwise, one  
main canvas layer.


That would require special casing canvas in  
http://dev.w3.org/csswg/cssom-view/#scroll-an-element which I'm not sure  
is a good idea. Why don't you just dispatch a synthetic scroll event?



--
Anne van Kesteren
http://annevankesteren.nl/


Re: [whatwg] should we add beforeload/afterload events to the web platform?

2012-02-04 Thread Adam Barth
On Fri, Feb 3, 2012 at 10:47 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 2/3/12 11:15 PM, Ian Hickson wrote:

 No, I agree with you that if the author is using HTTP styles on their
 HTTPS page that an attacker could screw with the page. But my point is
 that fixing that is easy: just move the styles to HTTPS. In the case of
 scripts it's not that easy because the scripts might be on third-party
 servers

 Styles are also commonly found on third-party servers...

 in complicated setups

 Likewise.

 But yeah, I'd love to hear from Adam here.

I've somewhat lost track of this thread.  If you're asking about how
dangerous it is to include HTTP styles in an HTTPS page, it's less
dangerous than script but more dangerous than images.  Chrome
classifies styles as active mixed content, which has a number of
effects, including triggering scarier UI.

One way to think about insecure styles is to imagine they let the
attacker completely control the appearance of the page (this is
actually not that far from the truth).  There are many pages where
controlling their appearance is almost as good as injecting script
into them.  For example, you can convince the user to type their
password into a text field that is actually a direct message to the
attacker, etc.

Adam


Re: [whatwg] Supporting scrollTop and scrollLeft on the Canvas element

2012-02-04 Thread Charles Pritchard

On 2/4/12 12:30 AM, Anne van Kesteren wrote:
On Tue, 31 Jan 2012 23:35:45 +0100, Charles Pritchard 
ch...@jumis.com wrote:
I'd like to see scrollTop and scrollLeft supported for the Canvas 
element. They would simply fire an onscroll event on the element, and 
do nothing else.
Many Canvas UIs use only one visible canvas layer, or otherwise, one 
main canvas layer.


That would require special casing canvas in 
http://dev.w3.org/csswg/cssom-view/#scroll-an-element which I'm not 
sure is a good idea. Why don't you just dispatch a synthetic scroll 
event?




Does the scroll event carry x/y information?

I agree, this is a special case for canvas -- the precedent set by 
input type=text is that form controls may have separate scroll semantics.


My proposal is not thought-out all the way, but I'm hoping it can float.

The idea here is to enable scroll with limited height/width canvas layer 
to work well.


This is going to be useful for context.scrollPathIntoView as well as 
simply running Element.scrollIntoView on elements within the Canvas 
sub-tree.


Currently, the scroll* attributes in Canvas are read only and set to 
zero. So, I think there is room to support them in the future.


-Charles






Re: [whatwg] di? Please?

2012-02-04 Thread fantasai

On 02/03/2012 12:22 PM, Ian Hickson wrote:

On Tue, 10 Jan 2012, Hugh Guiney wrote:


As I understand it, the main reason for rejectingdi  was that it
solves a problem that is allegedly CSS's job, but as an author who uses
dls quite extensively, adding a grouping element would really make my
life a lot easier.


There are a number of places in HTML where it would be nice to be able to
group things together -- just look at how often people stickdivs in
their pages for no purpose whatsoever other than styling.

This shouldn't be necessary. It's a limitation of CSS.

The right solution is for CSS to provide some pseudo-element or other
mechanism that introduces an anonymous container into the rendering tree
that wraps the elements you want to wrap.


I don't think this is a CSS problem. I think it's an HTML problem.
It's not just that you might want to style definition items, you
might also want to tag them with an ID so you can use them as a
target anchor. Or pick them up and do interesting things with them
via script. But you can't do any of these three things because you
can't wrap them in an element.

Pseudo-elements are a non-trivial thing to spec, and a non-trivial
thing to implement, and a comparatively confusing thing to use. Yet
you're suggesting that we use them to solve a problem that is not
even entirely solved by a new pseudo-element, rather than defining
an appropriate HTML element for the job. So what is it about defining
a real element that is so problematic that we're considering a pseudo-
element here?

~fantasai


Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

2012-02-04 Thread Charles Pritchard

On 2/4/12 11:28 AM, irakli wrote:

We have some significant obstacles on the path of fully optimized
Responsive Web Design, however. Responsive Images (smaller images for
smaller screens to optimize download times) and optimized CSS/JS (mobile
devices don't need the same JS/CSS as desktop browsers do) are the obvious
ones.


For those creating web apps, aiming for universal design and/or WCAG 
compliance, I strongly recommend having a window.onresize hook in 
addition to the window.onload hook. Together, they give you a fast and 
responsive means for asynchronous loading of your page, and support of 
browser zoom as well as mobile device resolutions.


I use anywhere between two to four ranges width. For Canvas based 
applications, I have to track DPI as well.


In a basic application, may use two ranges: = 720px (or 800px) vs 
larger, for width.

In a more complex application and UI, I may track both width and height.


I've seen someone get extreme, using spreadsheets to track many sizes 
while trying to maintain a pure CSS environment.
While that can work for many cases, I don't think it's tenable or 
advisable during development of most web applications.


When development has settled down a bit, it's an OK time to try to pull 
out more of the JS logic and put it into CSS classes.


WCAG requests that sites support a 2x zoom ratio. I strongly recommend 
authors test their site both at 2x zoom and at 50%. Browsers are 
supporting up to 500% it appears. While I encourage pushing boundaries, 
I doubt many authors will find 300 - 500% zoom levels to be achievable. 
But, it's still worth seeing what things look like.


-Charles


[whatwg] Comments before the DOCTYPE (warning message in validator.nu)

2012-02-04 Thread Leif Halvard Silli
Sat, 4 Feb 2012 04:28:35 + (UTC), Ian Hickson
 On Sat, 4 Feb 2012, Leif Halvard Silli wrote:
 
 If one tries to validate [...]

 Just a reminder to everyone that first of all, this list isn't really the 
 right list for discussing implementation specifics (we have an 
 implementation list for that if you're an implementor, but if it's just a 
 bug report then the best thing to do is to approach the implementors 
 directly via their bug systems),

Sorry, I did not read Henri's info [*] well enough. He mentions WHATWG 
there, but I skimped over that he spoke about the list you mention. 
Point taken.

[*] http://about.validator.nu/#reporting-bugs
-- 
Leif H Silli


Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

2012-02-04 Thread Bjartur Thorlacius
Feel free to propose e.g. Accept-Media to httpbis[1]. Bandwidth 
negotiation would be most useful.


Do make note of the dynamic nature of many viewports* and the fact that 
user agents may wish to render resources to multiple medias. The latter 
is rare enough to tolerate an extra roundtrip. Resizing viewports, 
however, should ideally not require a roundtrip.


For fast resizing, UAs must obtain layouts for all possible sizes before 
viewport resize. On fullscreen systems, these sizes might as few as one 
or two. Thing is, user agents could lay self-contained elements out 
recursively without author stylesheets.


User agents are all around much better suited to laying out 
self-contained elements than authors are. User agents can dynamically 
and intelligently apply new styles customized for their viewport. All 
authors have to do is semantically use nav, aside and link (so UAs 
can place them consistently) and group their content.


*Viewport: A window to which an user agent renders a document [2]

1: http://www.ietf.org/html.charters/httpbis-charter.html
2: http://www.w3.org/TR/CSS21/visuren.html#viewport


Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

2012-02-04 Thread Kornel Lesiński

On Sat, 04 Feb 2012 19:28:17 -, irakli ira...@gmail.com wrote:

The most optimal way to handle responsive images and optimize CSS/JS  
would be on the server-side. However, server-side does not have enough
information about device capabilities, resulting in emergence of all  
kinds of cruft-y solutions (e.g. using div's for img tags etc.) that  
should

not exist.


There are many factors that influence selection of images, and some of  
them (like zoom, available memory, screen/print media) can change after  
images are downloaded. Some factors don't depend on hardware capabilities,  
e.g. user may be roaming or exceeded bandwith allowance and thus strongly  
prefer small images even on high-end hardware.


Instead of sending a lot of information to the server, I think it would be  
better if websites declared what kinds of images are available and let  
browsers choose.


I think it's more likely that the few browser vendors will get client-side  
image selection right, than majority of websites will add good server-side  
logic that takes into account all factors. Look how hard it is for sites  
to get authenticated file downloads right — most of them use grotesque  
scripts that completely break all caching, resuming, MIME types and often  
mangle filenames. I'd be surprised if image selection scripts were any  
better. Even with a good script, it may be hard to get negotiated images  
properly served/cached via CDNs and proxies. Last time I checked presence  
of Vary header made responses non-cacheable in all major browsers, and  
that can be worse then serving wrong size.


If servers won't take into account all factors properly, then browsers  
will start lying in information they send to the server to force desired  
behavior, and capabilities header will degenerate like the User-Agent did.  
I can imagine all browsers reporting 320px to get 160dpi images, 960px to  
get 300dpi, and 1920px to get 100dpi, regardless of actual screen size.  
That starts happening with meta viewport and screen.width already.



OTOH giving browsers ability to select image by DPI/file size at any time  
opens up interesting possibilities, e.g. browser could load low-DPI  
versions of images necessary for initial layout of the page to show the  
complete page sooner (especially that mobile browsers show page zoomed out  
initially), and then replace images with high-DPI versions if  
bandwith/memory/user preference allows that or when user zooms in selected  
portion of the page.


On a page with lots of large images (a gallery or photoblog) browser may  
be forced to load low-DPI versions of images, even if it had enough memory  
to display each image _individually_ in high DPI, so the decision cannot  
even be made purely on per-request basis.


Given all the complexity involved, and potential for innovation in the  
browsers, I'd rather see a declarative solution in the markup (and not  
necessarily via a CSS media query, as this still keeps responsibility with  
developers, not browsers).


--
regards, Kornel Lesiński


Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

2012-02-04 Thread Boris Zbarsky

On 2/4/12 2:28 PM, irakli wrote:

Something as simple as if browsers passed along device's width/height
information


This information can change between page load and page unload (and in 
fact, it can change between the HTTP request being sent and the HTTP 
response being received).


All passing it would do is give the server a false sense that the 
information is time-invariant static.


-Boris


Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

2012-02-04 Thread Boris Zbarsky

On 2/4/12 5:57 PM, Bjartur Thorlacius wrote:

Do make note of the dynamic nature of many viewports* and the fact that
user agents may wish to render resources to multiple medias. The latter
is rare enough to tolerate an extra roundtrip.


Actually, printing an already-loaded page typically can't tolerate a 
roundtrip.  If nothing else, users have a tendency to try printing (or 
equivalently saving as PDF) after going offline.


-Boris