Re: [whatwg] Web DOM Core feedback
On Thu, 13 Jan 2011, Aryeh Gregor wrote: The HTMLCollection interface does specify supported property indices, but then also specifies behavior for out-of-bounds values which seems to conflict with WebIDL (returns null instead of throwing). Same for DOMStringList, DOMTokenList, and possibly others. Again, maybe it's WebIDL that should actually change here, not sure. The item() method can be called directly with out-of-range values. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Small consistency issue with HTML5 nav element examples
On Fri, 14 Jan 2011, Nicholas Zakas wrote: In section 4.4.5 (the aside element), an example is given that shows nav being used within footer. Section 4.4.3 (the nav element), explains that this would be an inappropriate use of nav (http://dev.w3.org/html5/spec/Overview.html#the-nav-element): Not all groups of links on a page need to be in a nav element - only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases, without a nav element. Minor inconsistency, but felt it was worth pointing out to avoid confusion. On Fri, 14 Jan 2011, Ian Hickson wrote: It doesn't say it's inappropriate, [just] that it's not necessary. It's still fine to use it there. I'll try to clarify that. I've updated the advice in the nav section accordingly, and made the advice explicitly non-normative. On Tue, 25 Jan 2011, Bjartur Thorlacius wrote: On 1/24/11, Ian Hickson i...@hixie.ch wrote: On Mon, 24 Jan 2011, Bjartur Thorlacius wrote: But then, when should hyperlinks be created with links? More or less never. link links don't show on most Web browsers. IMO browsers should implement link. link should be implementable cross-browser in CSS. Unfortunately, what we want and what we get don't always match. :-) Navigation links are clearly metadata, belonging to head. How do you distinguish what is data vs what is metadata? Generally, I categorize everything which isn't mentioned in the title or Content-Description (or would be, as there's usually none). No document would be described as My actual concern regard navigation links not forming a part of the linear body of the document, but still being in body. Navigation links will most likely be rendered out of band, potentially only on demand and paged/scrolled seperately from the body, or at the end of the document in one dimensional renderings (such as audio and text streams). They might even be triggered without being rendered at all, such as by scrolling out of range of the current document. It seems most authors desire far more control over their navigation links. On many pages, it's almost as if the navigation links are more important to the authors than the content, at least when you look at the amount of effort put into them... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for a web application descriptor
On 5/3/11, Cameron Heavon-Jones cmhjo...@gmail.com wrote: I would agree a command-level authorization is a better default, if only because it is necessary to have this level of granularity available. Agreed. The quantity of permission requests can be managed in an effective manner by the agent allowing the user to store their preferences for the next command or as a universal setting. If you manage to inform users that they'd then be authorizing for every purpose, usually without notice, not just for obeying the previous command. This is similar to what firefox does for launching unknown file types, session restore, or lots of other functions, although it would be in the context of a web application itself. How so? [snip stuff I completely agree with] For web applications to specify their required permissions would seem to introduce a duplication of specification. If a web application includes an image file upload which the user chooses to capture from webcam, first how is the application to know that the user would use a web cam? and second It isn't to know, nor to care. It receives an image, not a camera. what additional information is being specified in the permissions descriptor which wasn't already deductible from the inclusion of a file upload? This would additionally impose the scenario where applications include the use of some restricted system resource but fail to document the use in their descriptor, not an insurmountable problem but it draws any usefulness into question. Same problem as with Firefox on Android. There are a number of resources which are thought of having an 'application' scope which may make sense to be collated into a single manifest and with the ability for an agent to manage it as such. Yeah, if a single entity edits and signs multiple resources, it's unreasonable to trust one but not another.
Re: [whatwg] Can we remove forminput and formchange events and related dispatch methods?
On Thu, 20 Jan 2011, Olli Pettay wrote: On 10/22/2010 10:09 PM, Jonas Sicking wrote: On Fri, Oct 22, 2010 at 11:15 AM, Erik Arvidssona...@chromium.org wrote: On Oct 22, 2010 2:00 AM, Anne van Kesterenann...@opera.com wrote: Yeah, I don't mind moving these features to libraries. Anyone implemented them apart from Opera? Neither WebKit nor Gecko implements it: https://bugs.webkit.org/show_bug.cgi?id=26141 https://bugzilla.mozilla.org/show_bug.cgi?id=605997 IE9 beta does not have it either. This means that we should also remove dispatchFormInput/dispatchFormChange from the HTML5 spec, right? I agree, the events or at least the methods should be removed. Just to close the loop on this, these were removed a few weeks ago. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Browsers delay window.print() action until page load finishes
On Thu, 20 Jan 2011, Alexey Proskuryakov wrote: There seems to be no provision in the spec for a behavior Firefox and IE (and now WebKit-based browsers, too) have. If window.print() is called during page load, then its action is delayed until loading is finished. I haven't been able to reproduce this. I can reproduce cases where the browser entirely ignores a window.print() call (as allowed by the spec), but none where the call is delayed until later. Do you have a test case demonstrating this? I'd be happy to spec this, I'm just trying to work out what it means with respect to event firing, etc (the rest of the algorithm). Presumably, in many cases we want it to be synchronous as now, since pages presumably depend on being able to edit the DOM before and after. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Small consistency issue with HTML5 nav element examples
On 5/4/11, Ian Hickson i...@hixie.ch wrote: IMO browsers should implement link. link should be implementable cross-browser in CSS. Unfortunately, what we want and what we get don't always match. :-) I'll be a dick and quote your sig: Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' On a more serious note, implementing link can't be that hard. I'll probably patch my UA myself when I get the graphics layer working on my system (or just use links2). But I'm slowly coming to the conclusion that a should be used for creating hyperlinks that seem to belong to head, in a tree of htmlbodyasidea, for compatibility with mainstream UAs. My actual concern regard navigation links not forming a part of the linear body of the document, but still being in body. Navigation links will most likely be rendered out of band, potentially only on demand and paged/scrolled seperately from the body, or at the end of the document in one dimensional renderings (such as audio and text streams). They might even be triggered without being rendered at all, such as by scrolling out of range of the current document. It seems most authors desire far more control over their navigation links. On many pages, it's almost as if the navigation links are more important to the authors than the content, at least when you look at the amount of effort put into them... Sadly, the things authors desire may conflict with the things users desire. I also desire control over navigation links (among many other things). From authors, I desire only content. Bjartur Thorlacius yet another End-User(tm)
Re: [whatwg] Browsers delay window.print() action until page load finishes
04.05.2011, в 15:38, Ian Hickson написал(а): There seems to be no provision in the spec for a behavior Firefox and IE (and now WebKit-based browsers, too) have. If window.print() is called during page load, then its action is delayed until loading is finished. I haven't been able to reproduce this. I can reproduce cases where the browser entirely ignores a window.print() call (as allowed by the spec), but none where the call is delayed until later. Do you have a test case demonstrating this? Yes - for example, http://leiz.org/chromium/25027.htm. Basically, it's: script window.print(); /script pPrint me/p Safari 5 prints a blank page, while other IE and Firefox print Print me. WebKit nightly builds print Print me, too. Notably, we've seen different results in Firefox when printing file: vs. http: documents. I'd be happy to spec this, I'm just trying to work out what it means with respect to event firing, etc (the rest of the algorithm). Presumably, in many cases we want it to be synchronous as now, since pages presumably depend on being able to edit the DOM before and after. There is a number of subtleties, some of which we know about from a discussion in https://bugs.webkit.org/show_bug.cgi?id=43658. E.g. what happens if window.print() is called multiple times during loading, or if window.close() is called immediately afterwards (which happens on live sites in window.open()/write()/print()/close() scenario). And yes, we only defer window.print() if the document is still loading at the time of the call. There are obviously multiple definitions of loading possible for this feature. - WBR, Alexey Proskuryakov
Re: [whatwg] input element list attribute and filtering suggestions
On Tue, May 3, 2011 at 8:04 PM, Jonas Sicking jo...@sicking.cc wrote: You probably suggested this elsewhere on this list, but this sounds like a *really* interesting idea to me. I'd love to add experimental support for setting a property on the input element directly, which takes a JS object of some sort and builds a list out of that. I linked to my earlier feedback earlier in this thread, but it was buried fairly deep in my post: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024794.html The mozNoFilter attribute we added in Firefox 4. I don't see any use-case where you wouldn't want to use mozNoFilter. Why doesn't it just work that way always?
Re: [whatwg] Browsers delay window.print() action until page load finishes
On 5/4/11 6:58 PM, Alexey Proskuryakov wrote: script window.print(); /script pPrint me/p Safari 5 prints a blank page, while other IE and Firefox print Print me. WebKit nightly builds print Print me, too. Notably, we've seen different results in Firefox when printing file: vs. http: documents. Odd. The behavior should be pretty consistent: if print() is called while the document is loading we delay it to right after onload fires. There is a number of subtleties, some of which we know about from a discussion inhttps://bugs.webkit.org/show_bug.cgi?id=43658. E.g. what happens if window.print() is called multiple times during loading In Gecko's case if a print operation is pending then further calls to print() are effectively ignored. or if window.close() is called immediately afterwards (which happens on live sites in window.open()/write()/print()/close() scenario). In Gecko, if window.close() is called while a print operation is pending or while printing is in progress (printing is async), the close is deferred until the printing stuff is done. Note that the tab/window the user sees may still appear to go away in the meantime, but the internal data structures are kept alive until the print operation completes. Or at least that's what the code is trying to do; I haven't tested how it works in practice. And yes, we only defer window.print() if the document is still loading at the time of the call. There are obviously multiple definitions of loading possible for this feature. I _think_ Gecko's current code just aims for has onload started firing? -Boris
