Re: [whatwg] Supporting scrollTop and scrollLeft on the Canvas element
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?
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
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?
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
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)
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
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
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
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
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