Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On 1/27/12 1:30 AM, Ian Hickson wrote: On Wed, 5 Oct 2011, Henri Sivonen wrote: On Tue, Oct 4, 2011 at 9:54 PM, Boris Zbarskybzbar...@mit.edu wrote: What Firefox does do is block execution ofscript tags (but not timeouts, callbacks, etc!) if there are pending non-altenate parser-inserted stylesheet loads. This is necessary to make sure that scripts getting layout properties see the effect of those stylesheets. A side-effect is that ascript coming after alink will never see the link in an unloaded state... unless there's a network error for thelink or whatever. One exception: If an inline script comes from document.write(), it doesn't block on pending sheets. It runs right away. If it blocked on pending sheets, the point at which document.write() returns would depend on network performance, which I think would be worse than having document.written inline scripts that poke at styles fail depending on network performance. Note that this is not conforming. The spec does not currently define any such behaviour. Which part is not conforming? The exception for alternate sheets, the inline script inside document.write thing, or something else? -Boris
Re: [whatwg] Requests for new elements for comments
On Thu, 26 Jan 2012 21:43:07 -, Matthew Wilcox elven...@gmail.com wrote: Obviously this is not right - perhaps I'm not understanding your use case? Why would you want to specify an author as an attribute on the element? Not necessarily as an attribute, I would prefer an element. What is wrong with: article class=by-post-author pContent/p footer p class=authorWritten by: Person/p /footer /article Nothing tangible. It would serve my main use case of allowing articles by respected authors to be rendered before other articles or otherwise style them. I believe semantically stating authorship to be useful e.g. for searching a collection of documents for articles by a specific author, or conversely, blacklisting. Also, hCard fn allows for abbreviation of names I would find handy when screen space is scarce. But I guess those are less important than the first one.
Re: [whatwg] Including FLAC output in Audio Specs
On Wed, 12 Oct 2011, Charles Pritchard wrote: Currently, PNG and the Canvas tag set a solid precedent for including a lossless file format in media APIs. The PNG format, at its most basic, simply compresses a bitmap using deflate. I'd like to see the same precedent followed in some of the new media APIs. FLAC provides a lossless audio format which can be used to package audio data from items like the MediaStream .record method. How would we go about adding this into specifications? I'll point out that many vendors support JPEG in addition to PNG, but that's not part of the specs, and it is a lossy format. It'd be nice to see something like Speex supported by vendors on audio APIs, but like JPEG, it's something that should remain a lesser priority to supporting a lossless format. MediaStream record seems like it could accept a mime type, much as toBlob / toDataURL do on Canvas. That's one possible point of entry. Does anyone have feedback on this issue? Is there any push-back out there on supporting FLAC as a baseline format for audio input and output? Obviously, it is bandwidth heavy, as is PNG. Since the MediaStream API has moved to the WebRTC WG, I recommend raising this there instead. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Offline-Capable Meta Tag and API Indicates Application's Ability to Function Without Network Connection
On Wed, 12 Oct 2011, Brian Blakely wrote: Trigger a UA-native indication to the user that the current application's primary and entire collection of features can be used without a network connection. [...] This seems simple, almost superfluous, but it is of staggering importance. An online only stigma is of greatly growing impedance to the web platform's reputation as a software platform, and it persists among the vast majority of users. The latest versions of all major browsers will support features like DOM Storage and Application Cache very soon, but these features are largely ambiguous, even amongst the technically savvy. In addition to implementation of offline technologies, app authors are currently individually responsible for informing their users that an app can be used offline. This is not an adequate solution, and a universal notification that is UA-native would be far more effective at enhancing awareness. Because mere utilization of appcache and localStorage do not always make an application offline capable, offering a manual flag to authors allows a UA to complement, or override, its heuristic detections of this state. The Web must become known as a full software platform, instead of just a lite version of the native App Store experiences out there. In order to do so, its features must be more discoverable by users, and in a standardized fashion. On Thu, 13 Oct 2011, Justin Novosad wrote: I think this is a very interesting proposition. I would like to add that there should also be UA-native indication to the user that an app can become offline-capable upon request, along with a mechanism for requesting offline capability, and for triggering app data synchronization. The motivation being that there should be a universal way to manage the state of all offline capable apps at the browser/OS level. These seem like reasonable problems to try to address. I recomend approaching the browser vendors and asking if they would be interested in these features. Browser vendor experience, and seeing what kind of adoption these features get, is key to determining whether it's worth adding this or not. On Fri, 21 Oct 2011, Brian Blakely wrote: Data transfer ends when the user closes the browser, making huge 700MB applications impossible. How many are willing to keep a loading tab open for half an hour or more? What kind of app are you considering that needs 700MB at once? The current paradigm of page loading does not work for very large applications that need all of their assets before they can run functionally offline. Games and multimedia applications are almost always this way. For such apps I would recommend using the appcache feature and structuring the app so that it doesn't need to be fully cached before it'll work. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] How should overflow be handled when parsing integers?
On Sun, 16 Oct 2011, Daniel Bates wrote: How should overflow be handled when parsing integers? Use more storage. :-) If that's inpractical due to hardware limitations (e.g. the architecture is optimised for integers in specific widths) then you can handle it pretty much how you like. Currently in WebKit we consider such overflow a parsing error. That's fine. I suggest codifying the handling of overflow in the aforementioned sections. Generally speaking we try not to overspecify the handling of situations that occur due to hardware limitations, because different architectures have different constraints. It's not such a big deal in parsing numbers into a fixed-width storage space, admittedly, but consider a UA that _does_ try to grow its storage space to store arbitrarily sized numbers, and runs out of memory when doing so. It might be impractical to do anything but fail with an exception at that point. In fact, depending on the architecture, it might be impractical to do anything but crash. On Sun, 16 Oct 2011, Mounir Lamouri wrote: Gecko also considers that an overflow is a parsing error. Presto and IE6 doesn't seem to. The specs should probably mention this by whether consider it as a parsing error or request the UA to default to the highest value (which Presto and IE6 seem to do but not using the same value). I would recommend ignoring the attribute entirely rather than using an arbitrarily high value, personally. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] CACHE MANIFEST
On Sun, 16 Oct 2011, Francis Boumphrey wrote: This is a great new addition. However none of the current versions of Browsers provide an easy way to view cached files when the user is off line. Earlier IE's would give you an option, but this seems to have been done away with i later versions. Should not The spec require that compliant browsers provide an easy way to view cached files when the user is off line? This is a UI issue, so it's really up to the browsers. I recommend approaching them directly with this request. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas ScrollBar
On Thu, 20 Oct 2011, Bronislav Klu�~Mka wrote: Would it be possible to extend canvas specification to include scroll bar functionality? To add scroll bar, to manage scroll bar (total size, page size). Creating control based on canvas that needs scrollbar at this point is unnecessarily difficult at this point. It is expected that the component model feature being discussed in the public-weba...@w3.org mailing list will be how you make widgets on the platform. You wouldn't want to put the scrollbar in the canvas itself, since then it wouldn't follow platform native conventions, for example. Instead, you would create a widget which uses overflow:scroll with an element of the right height or width to create scrollbars, and then you would react to scroll events to repaint the canvas. On Thu, 20 Oct 2011, Bronislav Klu�~Mka wrote: b) how about creating user controls using canvas? (rich controls are better doing this way, one has pixel perfect control, full browser compatibility) like document viewer, rich listview/treeview control... Generally speaking, canvas isn't intended for anything but the simplest of interactive controls. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] keygen element
On Thu, 20 Oct 2011, Martin Boßlet wrote: In 4.10.14 The keygen element: Generate an RSA key pair using the settings given by the user, if appropriate, using the md5WithRSAEncryption RSA signature algorithm (the signature algorithm with MD5 and the RSA encryption algorithm) referenced in section 2.2.1 (RSA Signature Algorithm) of RFC 3279, and defined in RFC 2313. [RFC3279] [RFC2313] Wouldn't it be better to at least recommend sha1WithRSAEncryption or better even, sha256WithRSAEncryption, given that MD5 is generally considered as broken? Probably, but that's not what browsers do. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Signed XHTML
On Thu, 20 Oct 2011, Martin Bo�let wrote: With TLS we have a great tool for secure communication, we can do privacy and mutual authentication etc. with it. But I have worked on a couple of projects where clients were asking for the possibility to somehow store a receipt of some transaction that took place in their browser. For this kind of topic I recommend approaching this mailing list: http://lists.w3.org/Archives/Public/public-web-security/ -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] New attributes would degrade better than new elements
On Wed, 26 Oct 2011, Jukka K. Korpela wrote: New elements like nav and footer have the problem that some existing user agents don't recognize them, even for the purposes of styling. This is only a transient problem for a few years, and a minor one at that -- you can always add CSS to make them work in CSS-capable browsers, and it doesn't matter so much if they do nohting in non-CSS browsers. So if you want to use nav, then - unless you're using it for purely semantic reasons with no idea of styling - you need to use some special trick to make old browsers recognize it or assign your styles to some logically redundant div markup that you use in addition to nav. Old IEs need a special trick. Other browsers really don't, unless you consider setting the element's 'display' property a trick. Therefore, it would be much simpler, for compatibility with existing user agents, to use just div type=nav and div type=footer. I think the ugliness of that solution far outweighs any temporary transition issue. I understand that this should have been suggested years ago. But I didn't think of the issue, and it seems that neither did anyone else, aloud. Actually this topic was discussed in depth. Nobody needs new elements with no required functionality, really. The idea of more compact markup is pointless. This view is not shared by all. Personally, for example, I find the terseness of different element names to be of much help in writing more maintainable documents. On Thu, 27 Oct 2011, Kang-Hao (Kenny) Lu wrote: What else use cases do they serve? (This is a serious question since I truly don't know.) Specific elements have specific purposes, e.g. nav allows ATs to jump to or past site navigation blocks, and section allows table of contents outlines to be created (as do h1-h6, but section allows you to do it without having to renumber all your headings when moving stuff around). But in general, the main purpose is easier authoring. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] New attributes would degrade better than new elements
2012-01-27 21:33, Ian Hickson wrote: On Wed, 26 Oct 2011, Jukka K. Korpela wrote: New elements likenav andfooter have the problem that some existing user agents don't recognize them, even for the purposes of styling. This is only a transient problem for a few years, and a minor one at that -- you can always add CSS to make them work in CSS-capable browsers, No, that won't work on still existing versions of IE. Old IEs need a special trick. Indeed. They require JavaScript code. Therefore, it would be much simpler, for compatibility with existing user agents, to use just div type=nav and div type=footer. I think the ugliness of that solution far outweighs any temporary transition issue. div type=nav has been used for years, and it did not become any uglier. Transient problems that will be with us for years, as you admitted, far outweigh any subjective esthetics of more compact markup. Personally, for example, I find the terseness of different element names to be of much help in writing more maintainable documents. Then you could use authoring tools that convert nav, or whatever you prefer, to markup that all browsers understand. But in general, the main purpose is easier authoring. It is not easier but more complicated, since you need to write CSS code _and_ JavaScript code just to make all browsers understand your nav the same way they would understand div class=nav. Yucca
Re: [whatwg] Proposal: Offline-Capable Meta Tag and API Indicates Application's Ability to Function Without Network Connection
Hey Ian, What kind of app are you considering that needs 700MB at once? I'm considering videogames that the user would like to play offline (plane flight, subway, etc), as well as massive software packages like Adobe CS. A good application designer would allow the user to choose portions of the app that they would like to cache long-term, but suppose the user needs the entire thing? In that case, 700MB could likely lowballing by quite a bit. On Fri, Jan 27, 2012 at 1:34 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 12 Oct 2011, Brian Blakely wrote: Trigger a UA-native indication to the user that the current application's primary and entire collection of features can be used without a network connection. [...] This seems simple, almost superfluous, but it is of staggering importance. An online only stigma is of greatly growing impedance to the web platform's reputation as a software platform, and it persists among the vast majority of users. The latest versions of all major browsers will support features like DOM Storage and Application Cache very soon, but these features are largely ambiguous, even amongst the technically savvy. In addition to implementation of offline technologies, app authors are currently individually responsible for informing their users that an app can be used offline. This is not an adequate solution, and a universal notification that is UA-native would be far more effective at enhancing awareness. Because mere utilization of appcache and localStorage do not always make an application offline capable, offering a manual flag to authors allows a UA to complement, or override, its heuristic detections of this state. The Web must become known as a full software platform, instead of just a lite version of the native App Store experiences out there. In order to do so, its features must be more discoverable by users, and in a standardized fashion. On Thu, 13 Oct 2011, Justin Novosad wrote: I think this is a very interesting proposition. I would like to add that there should also be UA-native indication to the user that an app can become offline-capable upon request, along with a mechanism for requesting offline capability, and for triggering app data synchronization. The motivation being that there should be a universal way to manage the state of all offline capable apps at the browser/OS level. These seem like reasonable problems to try to address. I recomend approaching the browser vendors and asking if they would be interested in these features. Browser vendor experience, and seeing what kind of adoption these features get, is key to determining whether it's worth adding this or not. On Fri, 21 Oct 2011, Brian Blakely wrote: Data transfer ends when the user closes the browser, making huge 700MB applications impossible. How many are willing to keep a loading tab open for half an hour or more? What kind of app are you considering that needs 700MB at once? The current paradigm of page loading does not work for very large applications that need all of their assets before they can run functionally offline. Games and multimedia applications are almost always this way. For such apps I would recommend using the appcache feature and structuring the app so that it doesn't need to be fully cached before it'll work. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Offline-Capable Meta Tag and API Indicates Application's Ability to Function Without Network Connection
On Fri, 27 Jan 2012, Brian Blakely wrote: Hey Ian, What kind of app are you considering that needs 700MB at once? I'm considering videogames that the user would like to play offline (plane flight, subway, etc), as well as massive software packages like Adobe CS. A good application designer would allow the user to choose portions of the app that they would like to cache long-term, but suppose the user needs the entire thing? In that case, 700MB could likely lowballing by quite a bit. I think appcache handles this particular case reasonably well (modulo it's other known limitations, anyway). The caching progress can be easily reported to the user (either by the UA or the page), so the user can know that they should leave the tab open while it does the update, and yet the page is usable in the meantime. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] New attributes would degrade better than new elements
On Fri, 27 Jan 2012, Jukka K. Korpela wrote: 2012-01-27 21:33, Ian Hickson wrote: On Wed, 26 Oct 2011, Jukka K. Korpela wrote: New elements likenav andfooter have the problem that some existing user agents don't recognize them, even for the purposes of styling. This is only a transient problem for a few years, and a minor one at that -- you can always add CSS to make them work in CSS-capable browsers, No, that won't work on still existing versions of IE. Old IEs need a special trick. Indeed. They require JavaScript code. A trivial matter. Therefore, it would be much simpler, for compatibility with existing user agents, to use just div type=nav and div type=footer. I think the ugliness of that solution far outweighs any temporary transition issue. div type=nav has been used for years, and it did not become any uglier. I assume you mean div class=nav. Transient problems that will be with us for years, as you admitted, far outweigh any subjective esthetics of more compact markup. On the contrary. The transition issue is a short-term issue (on the scale of the age of the eventual period of time during which the features will exist), but the language design aesthetic is one that we will have to live with for the lifetime of the feature. Personally, for example, I find the terseness of different element names to be of much help in writing more maintainable documents. Then you could use authoring tools that convert nav, or whatever you prefer, to markup that all browsers understand. nav, to a sufficient approximation, is markup that all browsers understand. But in general, the main purpose is easier authoring. It is not easier but more complicated, since you need to write CSS code _and_ JavaScript code just to make all browsers understand your nav the same way they would understand div class=nav. This is a mere transition issue. You are welcome to avoid using the element for a few years until it becomes more widely supported. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Offline-Capable Meta Tag and API Indicates Application's Ability to Function Without Network Connection
I completely agree Ian, app cache would be the means by which a developer sends their assets to the user's local storage device. This proposal deals chiefly with standardizing the messaging around that. The developer sets up the application to be ready for offline use (via App Cache, localStorage, IndexedDB, cookies, etc), and informs the UA when the user can go off the wire. The UA then informs the user in a predictable way that will become familiar to them as they continue to use that particular client. Background downloading and other mechanics introduced in this thread enable a native-like app download process that is, again, always the same on the same UA, instead of varying from application to application. -Brian On Fri, Jan 27, 2012 at 4:50 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 27 Jan 2012, Brian Blakely wrote: Hey Ian, What kind of app are you considering that needs 700MB at once? I'm considering videogames that the user would like to play offline (plane flight, subway, etc), as well as massive software packages like Adobe CS. A good application designer would allow the user to choose portions of the app that they would like to cache long-term, but suppose the user needs the entire thing? In that case, 700MB could likely lowballing by quite a bit. I think appcache handles this particular case reasonably well (modulo it's other known limitations, anyway). The caching progress can be easily reported to the user (either by the UA or the page), so the user can know that they should leave the tab open while it does the update, and yet the page is usable in the meantime. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas ScrollBar
On 27.1.2012 20:02, Ian Hickson wrote: On Thu, 20 Oct 2011, Bronislav Klu�~Mka wrote: Would it be possible to extend canvas specification to include scroll bar functionality? To add scroll bar, to manage scroll bar (total size, page size). Creating control based on canvas that needs scrollbar at this point is unnecessarily difficult at this point. It is expected that the component model feature being discussed in the public-weba...@w3.org mailing list will be how you make widgets on the platform. You wouldn't want to put the scrollbar in the canvas itself, since then it wouldn't follow platform native conventions, for example. Instead, you would create a widget which uses overflow:scroll with an element of the right height or width to create scrollbars, and then you would react to scroll events to repaint the canvas. How does scrollbar on div, p, textarea etc. follow platform native conventions but scroll bar on canvas would not? On Thu, 20 Oct 2011, Bronislav Klu�~Mka wrote: b) how about creating user controls using canvas? (rich controls are better doing this way, one has pixel perfect control, full browser compatibility) like document viewer, rich listview/treeview control... Generally speaking, canvas isn't intended for anything but the simplest of interactive controls. HTH, Generally speaking, widgets are intended to be HTML container, which makes them far inferior to possibilities of canvas... simpler, but inferior (as is any HTML container at this point). Brona
Re: [whatwg] [CORS] WebKit tainting image instead of throwing, error
On Tue, 1 Nov 2011, Charles Pritchard wrote: I'd been using img crossorigin for everything... It was lazy but worked fine until the latest roll-out of Chrome. Now my local references fail the check. I have to use img for local images that I know are safe, and img crossorigin for images that I suspect are not safe. This is likely just a bug in Chrome, but it was rolled out quickly before going through the Chrome Canary process. Code example: img src=./localImage.png crossorigin may -fail- the crossorigin check even though the image will not set a dirty flag on Canvas. On Tue, 1 Nov 2011, Adam Barth wrote: Sorry about that. This is filed as https://bugs.webkit.org/show_bug.cgi?id=71053. I've got some time scheduled to look at this later in the week. I've fixed the spec accordingly. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
