Re: [whatwg] Canvas in Workers
On Wed, 9 Jan 2013, Mark Callow wrote: I would expect these wins to be equally important when doing animation in Canvas2D as I would double buffering to to avoid flicker. Are implementors interested in a way to make 2D rendering contexts use page flipping instead of double buffering? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Specification unclear about how HTMLElement.prototype.onscroll's getter/setter should behave for body elements
On Mon, 3 Dec 2012, Boris Zbarsky wrote: On 12/3/12 7:33 PM, Ian Hickson wrote: Note that onerror has a different type on HTMLElement and HTMLBodyElement. Yes, indeed. That's the biggest problem with forwarding to Window for the HTMLElement.prototype case for onerror here: the types are different. onscroll is a case where there's really no reason to use a different setter, agreed. So I've commented that out (and it's similar friends). That still leaves onerror though. Indeed. I would have no problem with just having HTMLElement.prototype.onerror's setter set an error handler on the body itself, like it would on any other HTML element, and likewise for the getter. Per our IRC discussion just now, I think I would propose that when a method/setter/getter from a prototype of interface A is called against an object that is of an interface B (or one of B's descendants), where B is a subclass of A, and B defines its own method/getter/setter with the same name, then it should throw. Hmm. That, as phrased, is pretty complicated to implement in a performant way, if the two methods/getters/setters have the same signatures... heycam, did we resolve this at the WebIDL level by any chance? Or is this still open? (If the latter, is there a bug# for it? Or is this an HTML problem I need to fix myself?) On Mon, 3 Dec 2012, Boris Zbarsky wrote: I have to ask: are there languages or runtime systems that have that sort of behavior on method calls (as opposed to in method implementations in special cases where the operation is nonsensical)? It seems weird to be requiring this behavior, in general. Most languages, if you invoke the method of a superclass on an object of a subclass that overrides that method in an incompatible way, will just let you crash the application. This isn't an option for us. In practice there are only a few of these cases, so implementations _could_ special-case them, rather than doing it at the binding level. If you have actual IDL in your pipeline, the compiler could flag which cases need this, and automatically generate tests to make sure they are done. It doesn't have to be a widespread performance impact. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Location object identity and navigation behavior
On Tue, 20 Nov 2012, Bobby Holley wrote: On Tue, Nov 20, 2012 at 9:46 AM, Ian Hickson i...@hixie.ch wrote: In thinking about this further last night, it struck me that while the proposed proxy mechanism was IMHO overly complex, there might be a simpler mechanism that still gets all the compatibility needs, and works for Mozilla, and isn't quite so crazy. I'm not a huge fan of this, but I'd be interested in what Adam thinks of it. Right now, as specced, each Document gets a Location object, but they all act the same: they all work on the active document and they all do security checks based on the active document, not the Location's Document. But what if, instead, we had one Location per Document, and it worked on that Document (not the active document), with the security policy being like Window, specific to its Document's effective origin, but instead of ever getting references to it, you only got references to a proxy that acted on the active document's Location? Wouldn't this effectively mean having a LocationProxy, just like WindowProxy? Yes. It differs from the original proposal in that there's multiple underlying objects and they're just proxied, not just one object that has its prototype and properties changed when the history is traversed. I'm certainly all for it, and think that it makes things much more sane, though I don't understand why this wouldn't propagate the magic that Adam doesn't want to propagate. I might be misunderstanding you though. Can you clarify? I agree that it does seem to be still more complicated than is apparently necessary, at least for implementations where determining the calling script's effective script origin is relatively easy. My understanding is that WebKit, old Gecko, and new IE do what the spec says currently, and old IE, Opera, and new Gecko do the proxying model. For authors, I don't really see the value of the proxying model. The current spec model is slightly simpler for authors, but only slightly, because you still can't access your own shims when the page is navigated to another origin. For implementors, I'm not really comfortable picking one side or the other here. I'm even less comfortable picking what's easy for Chrome over what's easy for Gecko. Browsers seem to be changing in both directions, and right now seem to be exactly equally split. So, I dunno. If it's a bust for authors, a tie for browsers, I guess the next level is spec writers, and, well, not changing anything is easier than changing something, so I guess that argues for not changing it? I've left the spec as-is for now, but I don't have a good argument one way or the other. Sorry for this unsatisfying answer. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Tue, 8 Jan 2013, Cameron McCormack wrote: On 16/12/12 9:34 PM, David Bruant wrote: WebIDL needs to embed in some way the notion of origin to enable throwing for security reasons in the right places. One idea would be to add an [OriginAware] extended attribute: * On operations (like in Boris case), an origin check would be performed before calling the core of the operation Why would this need to be on specific operations and not just be enforced on every operation? Most things don't have an origin. Origin checks are only done in some very specific places where you try to get an object's properties; what we're saying here is that for those properties, you also need to do the check when you run the code behind those properties (e.g. call a method), against the this. (Note: This is not what Gecko does. Some Mozilla people have been petitioning me to change the model in the spec to be more like Gecko's model.) Is it that we want to avoid the overhead of origin checking if we know that calling the operation does not leak information? Or it it that only a limited set of objects is exposed cross origin anyway, so we only need to check those? Both. For the actual wording of the check, we could either have a security check that is performed at the right time in #es-operations etc. and which HTML defines to do the origin checking, or we can make Web IDL aware of origins itself, and then HTML would define what origin different objects come from. In the case of Location, it's not about the origin of the object, it's about the origin of the active Document of the Window. See the Security sections in the HTML spec for examples of what we have now (there's one for Window, one for Document, and one for Location -- I think that's it). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Forms-related feedback
On Wed, 21 Nov 2012, Mounir Lamouri wrote: On 20/11/12 22:51, Ian Hickson wrote: On Tue, 20 Nov 2012, Mounir Lamouri wrote: At Mozilla, we think that the main use case for stepUp() and stepDown() is to create a UI with spin buttons: clicking on the up arrow would call stepUp() and clicking on the down arrow would call stepDown(). [...] Done, though I described it in a different way. (I hope it's equivalent.) I think there are two behaviour that you seem to have described differently: - in step 12, if you take the example page [1], setting the value to 21 and calling stepDown() should change the value to 20 and setting it to 19 and calling stepUp() should change it to 20. This how it is implemented in Opera and Firefox and this how the Chrome's UI behaves. As far as I understand the spec you wrote, those two examples would give respectively 10 and 30. [1] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1918 - I believe that when the value is set to below min and n 0, we should not change the value. Same thing for value below max and n 0. This is the behaviour all UA currently have with stepUp() and stepDown() (though, the previous spec was requiring that) and this is Chrome's UI behaviour. I think that behaviour makes more sense UX-wise because going down or up and having the value going the opposite way is just weird and unexpected. Done. For this: input type='number' min='10' step='10' max='21' ...if the value is 22 and you step up (with the UI), Chrome sets it to 21. (Opera does nothing.) Per spec, stepUp() now would leave this unchanged (like Opera). (I tried to test Firefox but I couldn't get my build to show UI for type=number. Not sure if I'm on the wrong channel or something?) Also, note that per the new spec if stepUp() or stepDown() are called with an argument that isn't 1, it's ignored if the value isn't on a valid step. So in the example above, if value=22 and you call stepDown(5), it only goes down to 20, not 10. Is that ok? Also, if you call it as stepDown(-2), it goes down to 20, it's not left at 22, because the argument is ignored and the method itself is used to determine the direction if we're not on step. Is that ok? Similarly, if you're at 10, and you call stepUp(1), it goes to 20, but if you call stepUp(2), it stays at 10, because 30 is out of range (max 21). Is that ok? [1] The only difference between Chrome's spin buttons behaviour and our proposal is that when value is the empty string, it is setting value to 0 and continue to the next steps (unless the 0 is below the minimal allowed value and n 0, in that case value=min). It might be interesting to specify something better than do nothing if value=. I'm open to doing that too; what would you preference be? Maybe if value isn't valid, we could have it changed to the step base or |min + (max - min)/2| and exit the steps if stepDown() or stepUp() is called. (I think even if stepDown(hugeNumber) is called, we should still just set the value and do nothing else.) I would tend to prefer step base mostly because it would know set it to the default value if there is a default value. However, I think step base is quite a bad solution for some types. Maybe we could use the default value if there is such a concept for the type or the step base otherwise? It's probably simple enough for authors to check valueAsNumber is not NaN and then have them set it to the value they want as the default, if they're calling the stepUp/stepDown methods. I've left this as throwing if the value isn't a number. On Sun, 25 Nov 2012, Scott Gonz�lez wrote: For any non-parsable value (including no value), we start at 0, take the step, then confine to a valid step within min/max. I think that makes sense for the UI, but for the methods I'm less sure, given how easy it is to check for this case and do whatever behaviour makes the most sense for the control. On Thu, 22 Nov 2012, Markus Ernst wrote: Am 22.11.2012 01:51 schrieb Ian Hickson: On Sun, 14 Aug 2011, Timo Beermann wrote: It should be able to implemet checkboxes, where by only activating/deactivating this single checkbox you can active/deactivate multiple other checkboxes. That is possible with scripting today, but it should be possible without scripting, only with HTML/CSS. Because some users deactivate Scripting (for security or whatever other reason) and on other computers (school, university, work,...) you are not able to change the settings, even if you want to. E.g. I use NoScript and only allow scripting on very few trusted sites, that really need it. I haven't added this yet, but it is already logged as a possible future extension, so it's possible it may be added in the future. What would be helpful though is examples of sites that do this kind of thing, so that we can study how necessary
Re: [whatwg] Script-related feedback
On Mon, 7 Jan 2013, Adam Barth wrote: Why not just introduce a keyword or pragma to JavaScript that tells the user agent to act as if the end of the Program production had been reached, and that it should treat the remainder of the file as another Program? This could even be done in a backwards-compatible fashion by having the syntax to do this be something that down-level clients ignore, e.g.: /*@BREAK*/ ...or some such. That approach is an in-band signal, which means it's vulnerable to injection attacks. If you can inject this, you can inject arbitrary code, so I don't see how this would be a problem. For example, consider a server that produces a JavaScript file of the following form: [...] var userData = ?php echo santize($userData) ?; [...] Currently, the rules for sanitizing using input are relatively straightforward (essentially, you just need to worry about a few special characters). Those simple rules would prevent anyone from inserting a pragma-like comment, too, so that's fine. However, if we implemented an in-band signaling we might well break these sanitation algorithms. How? I'm not suggesting changing any JS syntax, just making existing JS syntax be used as a signal. If making a comment do this is too dodgy, make it something like this: breakParsing(); ...and for down-level support, define an explicit breakParsing function that does nothing. If someone can insert a function call into JS, you've definitely lost already. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Location object identity and navigation behavior
On Mon, 7 Jan 2013, Bobby Holley wrote: Aside from concerns about stack introspection, the main downside of this approach is that it's a blacklist, rather than a whitelist (like our other security code), so we'll have to be extra careful when implementing anything new on Location. Please keep that in mind when updating the spec. ;-) Can you elaborate on what is a blacklist? The way it ended up in the spec is that everything on Location is blocked if it's a cross-origin access, except for the 'href' setter and 'replace'. This is an area that I've already screwed up the security model for twice, though, so I would have no trouble believing I screwed it up again... http://whatwg.org/html#security-3 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Mon, 7 Jan 2013, Boris Zbarsky wrote: On 1/7/13 6:41 PM, Ian Hickson wrote: Most things don't have an origin. Pretty much everything has an origin in practice: it's associated with some Window, hence can be treated as having the same origin as that Window. Per spec, even Windows actually don't have an origin. Things that have origins are URLs, Documents, images, audio and video elements, fonts, and scripts. Many of those things can have origins that are not that of the most obvious related (or in some cases any) Document. Origin checks are only done in some very specific places where you try to get an object's properties; what we're saying here is that for those properties, you also need to do the check when you run the code behind those properties (e.g. call a method), against the this. I'm not quite sure we're talking about the same thing here. Can you give an example of what you're thinking? Suppose you try to get the property from a Document whose origin doesn't match your script's origin. Right now, this throws a SecurityError, because of: # User agents must throw a SecurityError exception whenever any properties # of a Document object are accessed by scripts whose effective script # origin is not the same as the Document's effective script origin. -- http://www.whatwg.org/specs/web-apps/current-work/#security-document The check we need to add is for when you actually invoke the properties, in case you got the property from another Document and then apply it to this one. The check is the same -- if the Document that is the this to which the property is being applied doesn't match the origin of the script that is doing the applying, throw SecurityError. What _I'm_ thinking is that there needs to be a security check when someone does Document.prototype.getElementsByTagName.call(subframe.contentDocument). This is not the same security check as the one performed by subframe.contentDocument.getElementsByTagName (note lack of call; it never gets that far in the cross-origin case). This is independent of whether we're doing security checks on all property access or on some of them. Right. Specifically, the new security check (for compat we still need the old one too, though I guess in many cases it's now redundant) needs to be in getElementsByTagName()'s definition or in call()'s definition. (If the latter, we also need to put it in a number of other places, like the stuff that interacts with getters/setters.) So e.g. we could put it in call() and define it as checking whether you can obtain the property on the target object before actually executing any code. I don't want us to literally put the checks (in the spec) in each method / property of the four objects with these checks (Document, Window, Location, Storage), since that's a _lot_ of places to put these checks. We could put them in prose in the same places that have the access checks now. Or we could put them elsewhere. Where the current checks are makes the most sense to me, but I'm not sure exactly how to phrase them. Implementing different security models on the IDL level is a footgun of enormous size. We should simply have IDL methods throw if called with not-same-origin this or arguments, except for a whitelist. Except for having to define the origin of things for this purpose, yes, that's what I'm essentially saying. Not that we can have the argument about which interfaces are subject to this security check if you want to only limit it to some objects; or example you could argue that this is only needed on Window, EventTarget, Document, Node, and a few others. That's a separate argument from whether the security checks for those interfaces should be opt-in or opt-out. I don't see why EventTarget would be subject to this (it's implemented by things that need checking, but presumably everything that's implemented in that way should just be handled by that host interface the same way as everything on that host interface that isn't white listed). The only interfaces that are of interest here (that need them and their inherited and implemented interfaces checked) are Document, Window, Location, and Storage. At least, in the HTML spec, as far as I can tell. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Tue, 8 Jan 2013, Boris Zbarsky wrote: On 1/7/13 11:28 PM, Ian Hickson wrote: Per spec, even Windows actually don't have an origin. Things that have origins are URLs, Documents, images, audio and video elements, fonts, and scripts. Many of those things can have origins that are not that of the most obvious related (or in some cases any) Document. Yes, I know what the spec says. What I'm saying is that the spec is not doing anyone any favors by using origin to mean different things for different objects. I don't think it means different things, but I guess that's semantics. In particular, for images/audio/video the origin in the spec is the origin that's relevant for the _data_, not necessarily for the element itself. In the spec's security model, origins are never relevant for elements except when we're looking at the element's data. Right. Specifically, the new security check (for compat we still need the old one too, though I guess in many cases it's now redundant) It's not redundant, because nothing says that subframeDoc.getElementsByTagName is actually the WebIDL-defined method; it could be something the script in the subframe set up. So you have to block access to it no matter what. Agreed; by being redundant in many cases I didn't mean that we could do away with it, just that in many cases you effectively have to do the check twice (since in most cases the property isn't overridden). needs to be in getElementsByTagName()'s definition or in call()'s definition. (If the latter, we also need to put it in a number of other places, like the stuff that interacts with getters/setters.) I would vastly prefer that this check be in the definition of the [[Call]], because then it can be done on the binding level, when you're checking the this object anyway. Doing it in [[Call]] and the various equivalents for IDL attributes would be fine by me. So e.g. we could put it in call() and define it as checking whether you can obtain the property on the target object before actually executing any code. Is that actually needed? There are properties you can obtain on objects cross-origin (like window.top) that I see no need to allow via this backdoor since no content depends on it now. So I would prefer simply checking whether the origin of the caller matches the origin of this. Well right now this doesn't necessarily have an origin. Also, consider Location. If you have a Location object and then navigate its browsing context and then call something on it, you need to check that the calling script doesn't match the origin of the new active document, not the origin of the Location object's Window's Document. I don't want us to literally put the checks (in the spec) in each method / property of the four objects with these checks (Document, Window, Location, Storage), since that's a _lot_ of places to put these checks. We could put them in prose in the same places that have the access checks now. Or we could put them elsewhere. Where the current checks are makes the most sense to me, but I'm not sure exactly how to phrase them. Or you could spec what Gecko does, which is that any WebIDL call gets such a check, and then it's just defined in WebIDL. ;) Doing a check on _every_ call seems rather expensive for implementations that don't use Gecko's security model compared to only doing a check on those interfaces that matter. Given any script-exposed object, it already has to be associated with a specific global. WebIDL makes this a requirement, since you have to find the right prototype object for it. A Location object has multiple prototypes (one for each origin that accesses it). At that point, you have a Window to work with, and a Window has an associated Document, and that has an origin. For object-access checks (again, as opposed to data-access checks), this is the right origin to use. For Storage, the access check has to be the actual origin of the Document, not the effective script origin as it does for Window and Document. I don't see why EventTarget would be subject to this (it's implemented by things that need checking, but presumably everything that's implemented in that way should just be handled by that host interface the same way as everything on that host interface that isn't white listed). EventTarget isn't implemented. It's inherited from. You're right, my bad. The only interfaces that are of interest here (that need them and their inherited and implemented interfaces checked) are Document, Window, Location, and Storage. At least, in the HTML spec, as far as I can tell. var myGetter = Object.getOwnPropertyDescriptor(Node.prototype, firstChild).get; var node = myGetter.call(crossOriginDoc); This should throw; we agree on that, right? Assuming the script's effective
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Tue, 8 Jan 2013, Boris Zbarsky wrote: On 1/8/13 1:42 AM, Boris Zbarsky wrote: On 1/7/13 11:28 PM, Ian Hickson wrote: The check is the same -- if the Document that is the this to which the property is being applied doesn't match the origin of the script that is doing the applying, throw SecurityError. Actually, that's not enough. You have to security-check arguments too. Otherwise this: document.createTreeWalker(crossFrameDoc, etc); would be bad. (Note that right now the DOM spec fails to handle this, which is about what I would expect out of people creating APIs, which is why I would really prefer we define this on a low level where people can't screw up by forgetting it.) I don't know about Document, but I can definitely think of APIs where it makes sense to be passing Window objects from other origins. (For example, one could imagine a PortCollection analogue for Window.postMessage() where you push the destination Window objects into an opaque object and then have the browser iterate over them.) I would be fine with an annotation on Document and Window that says that you can't pass them in as arguments when they're cross-origin except if the method's argument has itself been annotated with a I know what I'm doing marker. (Dunno how this would work with Location and Storage.) But if there's only one API that takes any of these four object types currently (I couldn't find any that took Document or Window in the HTML spec in a cursory look) then maybe it's not worth the bother. Wack a mole isn't _so_ bad if it's one mole a decade. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] menu and friends
On Fri, 4 Jan 2013, Jonas Sicking wrote: On Fri, Jan 4, 2013 at 4:56 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 4 Jan 2013, Jonas Sicking wrote: Gah, strongly agree. Simple example - I use Back constantly in the context menu, and would be really pissed if pages could easily kill that. [...] Can you elaborate on what you mean by if above. It's already the case that pages can in all popular browsers. Please note that none of the proposals here remove that option. Not even the proposal from Ian. The spec allows the browser to remove that option. (User agents may provide means for bypassing the context menu processing model, ensuring that the user can always access the UA's default context menus) It even gives an example of how to do it (For example, the user agent could handle right-clicks that have the Shift key depressed in such a way that it does not fire the contextmenu event and instead always shows the default context menu). Sure, but this is purely academic-- I was just disagreeing with the statement Not even the proposal from Ian. unless browsers actually do this. Firefox does, though its interface for it is somewhat arcane (about:config tweaking), right? Anyway, I don't really understand what we're arguing here. It's not generally controversial that we should take care in adding new features. For this one, we have one browser that implements something somewhat like what the spec now has, and that's it. We have a concern (that some browsers will avoid the feature entirely if the UA shows the items in addition to the default items), but we don't have much data to support this, and we have no data exploring whether any of the various mitigating ideas (submenu, only including critical UA items, shift key to show the original menu, never showing the original menu) satisfy authors or users sufficiently to avoid having to add more syntax. Until we have more data, not doing anything in the spec is the right move. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Add CanvasRenderingContext2D.fillRule with nonzero (default) and evenodd options
On Fri, 10 Jun 2011, Chris Jones wrote: In 2D canvas, determining whether a point is inside a path is currently always done using the non-zero winding rule. I propose extending 2D canvas to allow determining inside-ness using the even-odd rule. I've added this to the spec. On Wed, 2 Jan 2013, Dirk Schulze wrote: There was a complain on the webkit bug report if fillRule should be part of the graphics state or not. Did you investigate what current 2d graphics libraries do (qt, Cairo, CG, ...)? Is it part of the graphics state there? I have made it be part of the graphics state in the spec; it would be unusual in the API for it not to be. However, if this doesn't match implementations, please let me know. On Wed, 2 Jan 2013, Rik Cabanier wrote: this features is not a trivial as it seems. Adding this will necessitate updates to the algorithms that deal with paths and the outlining of strokes and text. Can you elaborate on what updates are needed? I couldn't see any that actually needed to be changed. As Dirk mentioned, instead of making it part of the graphics state, it's more likely better to make it part of the fill or clip operator like SVG, PDF and PostScript. That seems like it would be inconsistent with the rest of the canvas API. In addition, the path object will need to be extended so it can deal with this idiom. Can you elaborate on how this affects the Path object? It seems like it would be somewhat orthogonal. The easiest way to implement this, would be to leave the core interface of canvas alone and just extend the path object with winding rules and a method to 'simplify' a path so it can be drawn with any winding rule. This doesn't seem like it would be easier... in particular, fillRule is now implemented in two browsers, so the implementation cost for them would be zero, and they don't yet implement Path at all, so the implementation cost for Path would be quite high, even without simplify. :-) On Wed, 2 Jan 2013, Rik Cabanier wrote: However, just look at how stroke is implemented in the Canvas 2d spec or how you can create paths by stroking or stroked text. They're all affected by the winding rules. How so? (The description on how to do strokes in the spec is very wrong, but that can be addressed later) Can you elaborate on this? If there's a mistake obviously I'd like to fix it... Dirk and I did a bit more research and found that SVG, PDF, Flash, PostScript, Skia, Core Graphics and Direct2D all have the winding rules as part of the fill operator. It seems strange that canvas would choose to have a different interface... People using the canvas API are more likely to know the canvas API, and thus want extensions to be consistent with the canvas API, than they are to be familiar with PDF, Flash, PostScript, Skia, Core Graphics, or Direct2D. Incidentally, of those, I'm only familiar with SVG, and SVG is similar to what I specced (indeed I don't see how it could be part of the operator since it's a declarative language). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Add CanvasRenderingContext2D.fillRule with nonzero (default) and evenodd options
On Thu, 3 Jan 2013, Rik Cabanier wrote: I have made it be part of the graphics state in the spec; it would be unusual in the API for it not to be. However, if this doesn't match implementations, please let me know. Do you mean browser implementations or graphic libraries? AFAIK all graphic libraries except cairo are different. I'm unsure about the browsers. Implementations of the spec (i.e. browsers). On Wed, 2 Jan 2013, Rik Cabanier wrote: this features is not a trivial as it seems. Adding this will necessitate updates to the algorithms that deal with paths and the outlining of strokes and text. Can you elaborate on what updates are needed? I couldn't see any that actually needed to be changed. One of the intents of the path object is so you can 'accumulate' the regions that were drawn so you can set them up as hit regions. It is? I don't think that's one of the use cases I've seen before. It's an interesting use case, though, true. This means that a hit regions can contain shapes that were drawn with different winding rules. The current path syntax does not allow you to store this information so you can't set up a hit region that was drawn with an [even-odd fill]. The Path objects just store paths, not filled shapes, so you can't really store non-zero-based shapes any more than even-odd-based shaped, if you're going to mix them. If this (the region accumulation thing) is a use case we should support, then we need a way to add paths together in a way that converts all the paths to a specific fill rule type (ideally to be agnostic of the rule). As Dirk mentioned, instead of making it part of the graphics state, it's more likely better to make it part of the fill or clip operator like SVG, PDF and PostScript. That seems like it would be inconsistent with the rest of the canvas API. Winding is specific per draw and unlikely to persist across several draw commands. This makes it different than color or the stroke style. I'd have thought that would make it exactly like the stroke style. The easiest way to implement this, would be to leave the core interface of canvas alone and just extend the path object with winding rules and a method to 'simplify' a path so it can be drawn with any winding rule. This doesn't seem like it would be easier... in particular, fillRule is now implemented in two browsers, so the implementation cost for them would be zero, and they don't yet implement Path at all, so the implementation cost for Path would be quite high, even without simplify. :-) It's easier because of all the other work that's necessary to make this feature work correctly. So, yes, it is easier now because they don't rely on the spec to implement stroking and they don't have an implementation for paths. However, the spec is supposed to be followed (right?) and at some point, paths should be implemented. Going the easy way now will give a headache later. I'm happy to defer to the browsers vendors on this -- browser vendosr, what would be simpler for you to implement? On Wed, 2 Jan 2013, Rik Cabanier wrote: However, just look at how stroke is implemented in the Canvas 2d spec or how you can create paths by stroking or stroked text. They're all affected by the winding rules. How so? For instance, take a figure eight that is stroked. If you draw it out, you will see that you cross 2 lines to get to the middle which means that there will be a gap when doing an [even-odd fill]. Could you elaborate on this? How would you propose this should be changed? (The description on how to do strokes in the spec is very wrong, but that can be addressed later) Can you elaborate on this? If there's a mistake obviously I'd like to fix it... I'm unsure where to begin... If you could just file bugs for each mistake, that would be great. http://whatwg.org/newbug -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] ProgressEvents for Images
On Thu, 3 Jan 2013, Glenn Maynard wrote: It might make sense to fire onerror if the image doesn't get loaded because images are disabled. Guaranteeing (or coming closer to guaranteeing, at least) that onload or onerror will always be fired would reduce the differences in event flow when images are disabled. When images are disabled, the image will typically be loaded when the user requests that they be loaded, which is when onload should fire. I think it'd be really confusing to have fired onerror first. The particular case above should be fixed, at least in the most common cases, by auto-revoking blobs, since you'll no longer need to carefully call revokeObjectURL. (I've come to the conclusion that URL.revokeObjectURL was a very badly flawed idea, since it introduces manual resource management in a platform not designed for it.) I'm not exactly clear on what exact words are needed here. If you could file a bug cc'ing the relevant people with a description of how to make this work, that'd be great. (I don't think this should be special-cased for img; there are dozens of other places in the spec where a URL may or may not be fetched for various reasons.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Styling details
On Wed, 2 Jan 2013, Cameron McCormack wrote: I'm wondering if anybody has had any further thoughts on how summary and details should be made stylable. Like most widgets, I think the answer is Web Components. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Styling details
On Wed, 2 Jan 2013, Anne van Kesteren wrote: On Wed, Jan 2, 2013 at 8:53 PM, Ian Hickson i...@hixie.ch wrote: Like most widgets, I think the answer is Web Components. As far as I can tell styling form controls is an unsolved problem and Components does not seem to be tackling it. We always play the Components card (and before that the XBL card), but the work thus far does not allow for altering how input is displayed, or subclassing textarea somehow. After a decade of waiting for this, I think it might be time to start calling this vaporware. Wait, Web Components isn't solving this? I thought this was one of the main use cases of Web Components. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Styling details
On Wed, 2 Jan 2013, Boris Zbarsky wrote: On 1/2/13 4:37 PM, Ian Hickson wrote: Wait, Web Components isn't solving this? I thought this was one of the main use cases of Web Components. [...] and it is certainly not doing: 4) Defining the browser-defined custom widgets using the capabilities of #2 such that authors can in fact style them. Why not? This seems like a pretty core feature. Without being able to do this, how can anyone reliably extend an existing widget, for example? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Sortable Tables
On Thu, 27 Dec 2012, Tab Atkins Jr. wrote: On Dec 27, 2012 6:04 PM, Ian Hickson i...@hixie.ch wrote: 2. What values should the sort property allow. One idea is that it takes a JS function similar to what JavaScript's sort function takes. If you leave it out then it just does alphanumeric sort. I was going to have a comparator function, but I couldn't see a sane way to make it work in the face of hostile functions that mutate the DOM, so I dropped it. You can do custom sort orders by giving a key in the data element's value= attribute, though. In JS, the comparator passed to sort() can potentially mutate the array that's being sorted, or delete it entirely. JS engines cope somehow. It's silly to not support a custom comparator here, since any problems you can possibly come up with are already present in the existing Array#sort function. If you can work out how to spec it, I'm all for it. I couldn't figure out how to do it in a way that didn't have a very high chance of being misimplemented and probably becoming an attack vector. I don't think an array is as dodgy as DOM manipulation, by the way. For example, arrays don't have origins, you can't change their prototype by appending the entries to another document, you can't navigate away from an array, you can't make one entry in the array be a child of another entry in the array, when sorting an array you only have one list of entries to sort, not one per column, and you use the same comparator for all entries, you don't mix it with a non-JS comparator. And that's just the problems I could think of off the top of my head; I'm not at all convinced I even understand the problem well enough to enumerate all the issues. Note that using the 'sort' event you can manually implement the sorting if you want to; it'll fire whenever the browser would otherwise sort. So the capability is there, just not in the convenient comparator function form. (Canceling the sort event overrides the UA's normal sorting behaviour.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] menu and friends
I've just checked in a somewhat large redesign of how context menus work in HTML. It's much more similar, though not identical, to what Firefox implements. It drops the command element, adds a menuitem element, introduces a button type=menu feature, and drops menu type=toolbar. High-level overview: * There's now three features of relevance here: 1. Toolbars. 2. Context menus. 3. Pop-up menu buttons. * Toolbars are nothing more than a div with the element name menu. There's no magic at all, no special content model, it's all CSS for styling, you use regular form controls to fill the toolbar. * Context menus and pop-up menu button menus use menu type=popup. The only children allowed for these elements are menuitem, hr for separators, and menu label= for submenus. * menu type=menu menu=id menu type=popup id=id defines a pop-up menu button. * menuitem has all the stuff that command used to have, including menuitem command=foo to point to another element (e.g. an a href, button, option, etc) and accesskey=. * menuitem is void (requires parser changes). * command is entirely gone. (Actually, I renamed command to menuitem and made it so it's only allowed in menu.) I would love input from implementors regarding whether this is something they are more interested in implementing than what came before. On Wed, 28 Nov 2012, Ian Hickson wrote: 1. Styling of toolbars and menu buttons is just not defined. Toolbars could be a purely stylistic issue, to be solved either exclusively by CSS, or CSS plus a component/widget binding model (whatever solution we end up with for that). I've made the type=toolbar state be a regular div-like context. Authors are on their own again for making toolbars for now. 2. Nobody is implementing it, in particular, the algorithm that converts HTML elements into a menu structure seems unpopular. I've dramatically simplified this algorithm. It now only consists of menu, menuitem, and hr. (We can drop hr if people don't like that; it's actually redundant with the handling of menu without a label.) With type=button, CSS would apply to the menu and menuitem elements, maybe with a limited set of properties applying. Long term, we look to XBL or Web components or whatever for styling. I haven't got a solution for drop-down button styling. The menu in this scenario is display:none, so I can't get any styles out of it to affect the styling of the drop-down menu. I'm open to suggestions for how to fix this; maybe the solution is to have something like: display: compute-style-but-do-not-render-anything-in-flow On Wed, 28 Nov 2012, Eduard Pascual wrote: I have put a first example on http://std.dragon-tech.org/mainmenu.png All you can see there is doable with plain CSS and HTML. It doesn't even use any CSS3 features. In fact, the whole thing works fine in IE8. As Fred Andrews mentioned, menus are quite easy to achieve with no scripting, as long as one stays within hover-based menus. Of course, most of the buttons and items in the screenshot require JS to actually do anything, but that's because of the app's own complexity. All the stuff in that window should be pretty much accessible (everything in there are ul's, li's, and img's with matching @alt and @title for the toolbar, which contains only shortcuts anyway, and load's of @onclick attributes that could be easily replaced by a's with @href's on a more web-ish scenario). In summary, menu bars and tool bars are quite a solved problem I don't think a pile of CSS should be needed for this, though, that's the problem. Let alone any JS: Now, here is when stuff gets serious: http://std.dragon-tech.org/contextmenu.png To be honest, I hate most of the code behind that with a passion... and I wrote it! I get paid for making stuff work, and thus I make stuff work, no matter what it takes. The context menu requires JS to display at all. It overrides the browser's native menu (which sometimes would be useful). There is a huge, empty, transparent div covering the whole iframe (the main area on the screen with the table on it) just so it can catch clicks and dismiss the menu. The context menu key (that nice thing between right Ctrl and the Windows key) doesn't do anything (doesn't trigger neither my menu nor the browser's) when the iframe has focus. Don't get me wrong, I quite love what I pulled off, and so do most of the app's users; but I loathe the truckload of crap code I have to feed the browser for everything to work as intended. Ideally you should just have to describe your toolbar or context menu in HTML and be done with it. * A mechanism (most probably an attribute + a CSS pseudo-class, or maybe even recycling :hover) to show click-based menu bars some script-less love. Traditional menu _bars_ are not something that I've solved with this update (specifically, the part where you click on one menu bar's label and then hover over
Re: [whatwg] menu and friends
(Oops, in my earlier message I cc'ed people instead of bcc'ing them, and this means reply-to-all replies are going to get caught in the mailing list software's filters. If you reply to this thread, please don't forget to strip the cc list down to nothing or only one or two people. If you forget, let me know that I should go unstick your e-mail from the mailing list filters.) On Fri, 28 Dec 2012, Jonas Sicking wrote: I think it would make sense for browsers to skip the less important menu items (those that are accessible via the menus, for instance) when showing a context menu that the author is providing. (But then, I think it would make sense to not show those ever.) But for things that are only sanely accessible via the context menu, I don't see why we'd drop them. I would mostly agree with your reasoning here if it weren't for the fact that all UAs by default already allow webpages to hide the context menu of any part of the page. Yes, I don't understand why browsers do this. It drives me crazy, as a user. As long as that remains the case we are giving authors two options: A) Use pile of divs to render context menu and get full control over what is rendered in the context menu. B) Use menu to create a more accessible menu, but accept that they will always be listed together with a list of UA items. Browsers don't _have_ to show their items with the contextmenu= menu. If the two choices above are the only choices, then it seems to me that browsers should just not include their menu in the contextmenu= menu. * more options isn't always equivalent to better UX. I.e. even a website that has the intent and knowledge to design the, for the user, perfect UX would hide many or all of the built-in menu items in many cases. Right, this is why I suggested that the UA should drop all non-context- specific items when there's a page context menu. So e.g. for Firefox, in the default (context menu on body) case, keep Inspect Element and View Background Image, but drop everything else. All of this makes me think that in very many cases authors will choose option A above. In that case, when would it make sense for the browser to ever include the default menu items? i.e. why not make nodefault the default? Additionally, the nodefault attribute proposed in [1] can be treated by the UA as a hint without risking pages breaking. For example it could choose to hide only non-critical menu items. Or hide none of them but move them into a sub-menu. Why not do this anyway, always, and forego the attribute? While mean that authors still wouldn't have 100% control over the UX, they would have dramatically more control than as the proposal stands now, heavily tipping the scale towards option B. The proposal as it stands now is that the browsers can show only the page's context menu, only the user agent's context menu, or anything in between. I don't think it's heavily tipped in either direction. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Including HTML more directly into SVG
if they were, I don't see why this would be better than introducing a better version of foreignObject that shrink-wraps. Doing that wouldn't require any changes to CSS or SVG or HTML except adding a single new element to SVG with a simple-ish processing model, and a minor change to the HTML parser. Specifically, in http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inforeign (section 12.2.5.5 The rules for parsing tokens in foreign content), the rule that makes any HTML element pop the stack of open elements until it closes the SVG element would need to be removed. I'm aware that this was put in place to avoid breaking a few pages that, seemingly for no reason, include an svg tag at the start of their page with no matching /svg, as including the HTML directly in the svg element would suppress their rendering. However, with my suggested change, these pages would continue working, albeit probably with a slightly different rendering. Dramatically different rendering. The entire remainder of the page would end up stacked on top of itself, if I'm understanding what you're describing correctly (treat all the children of svg as pos:abs). If this is unacceptable, it's acceptable to me to require a small, simple wrapper element that accomplishes the same thing as foreignContent, but automatically places its contents in the HTML namespace and auto-sizes itself, and have the parser key off of that. This should be avoided if possible, though, as it's annoying for authors with no direct benefit to them. I think that's a far simpler and clearer solution, both for specs, implementors, and most importantly, authors. For context, consider word processing programs like Pages or Word. They tend to have two modes -- one where there is flow text with floating or overlapping objects (SVG blobs, in our world), and one where everything is positioned and if you want text you put in a text box (foreignObject, in our world). I don't know of any markup language or graphics system where paragraphs are conceptual siblings with paths and shapes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] menu and friends
On Fri, 28 Dec 2012, Jonas Sicking wrote: I don't think it's a good solution to leave it undefined if all/none/some of the UA menuitems are displayed by default. While it on an API level won't break anything, authors consider as breaking a lot more things than APIs not behaving as expected. I'm happy to give guidance that happens to match what the browser vendors want to do anyway, but I don't think it makes sense to make a page- undetectable UI detail like this a conformance requirement. So are you proposing that the default should be that no UA menu options are displayed. I.e. the default being as if nodefault was set? As a user, I would hate that. But if you as a browser vendor are telling me as a spec writer that this is what would be needed to convince authors to not use divs for context menus, then yes. As a user, what I would like to be the behaviour, without the ability for the author to override it, is for the context menu to have the author's context menu items plus the context-sensitive items that cannot be accessed via the regular menus (e.g. Inspect Element, View Image, Copy Link Location, that kind of thing). I guess I could live with that as long as there was a way for the page to opt in to displaying items. It would allow adding more finegrained control over which categories of menu items are turned backed on which could be neat. I'm very skeptical about adding any kind of control here before we have broader implementation experience. Once we do, then it will be revisited anyway, since we have this bug on file: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12999 (I regularly reopen all the bugs marked LATER and go through them again.) Note that I didn't say always but many cases. I do think it's the case that in many cases displaying the UA menuitems is desirable. A good example of this is menu items that control access to the clipboard since that's something that webpages can't implement themselves. Most browsers do not permit reading and writing to the clipboard arbitrarily. Aren't those items accessible from the main menu? What items are there that it sometimes makes sense to expose but othertimes does not make sense to expose? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should scrollbars move focus?
On Mon, 22 Oct 2012, Ojan Vafai wrote: On Fri, Oct 19, 2012 at 3:43 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 19 Oct 2012, Elliott Sprehn wrote: I was working on a bug recently where authors had complained about WebKit's behavior where clicking a scrollbar unfocuses the activeElement. What's particularly quirky is that the window scrollbar never moves focus in any browser I tried, but overflow scrollbars inside the page *do* move focus in WebKit, IE and Opera but not in Gecko. From the spec's point of view, I think this is just something where you're supposed to try to match the host platform conventions. This doesn't have to be specced, but it also doesn't really seems to be a platform convention issue. The platforms that have scrollbars are all the same (i.e. clicking on the scrollbar never moves focus) and no browser fuller matches platform that convention. On Mac, clicking the scrollbar moves focus in at least some native apps. For example, TextEdit: Type enough text to have a scrollbar, open the fonts panel (Command+T), click the search field, then click the scroll bar in the document window, and focus moves to the document window. But it may just be that the conventions are more subtle than that (e.g. window gets focused, but not the specific widget). Gecko's behavior is most consistent with that, except Gecko *does* move focus if you click on a textarea scrollbar. It seems especially bad that you get a different behavior if you click on the scrollbar of the window vs. the scrollbar of an overflow:auto element that fills the window IMHO all the cases where this is inconsistent with the platform conventions are bugs, but that's a UA decision really. Anyway, if we're agreed that it's out of scope of the spec, I'm good. :-) On Fri, 26 Oct 2012, Elliott Sprehn wrote: So what's the consensus here? Should WebKit have Gecko's behavior? Should we unify the world and make scrollbars never move focus even on textarea? :) I think it should just match the native platform conventions, but really that's up to you. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] checksum attribute in a href tag
On Thu, 25 Oct 2012, Mikko Rantalainen wrote: Ian Hickson, 2012-10-24 19:28 (Europe/Helsinki): Anyway, if you have memory corruption there's nothing to say the corruption won't occur _after_ you've done the checksum verification. In particular, there's nothing to say it'll happen between receiving and decoding the packets over TLS and comparing the packets to the checksum, and not either before (in which case TLS will catch it as part of its own integrity checking) or after (in which case the checksum won't help). That's a pretty narrow window. My guess would be that people will screw up their hidden metadata (e.g. updating the .img file without updating the HTML file) more often, much more often, than the checksum will catch an error. That might be true, I really don't know. I'd guess that this attribute would be used pretty seldom but in those cases the correctness of transferred file would be important enough to take the possibility of false positive. If it would be used pretty seldom, it's probably not the highest priority in terms of things we should add. :-) In addition, if the correctness of the file is important to you and the downloaded file does not match the hidden metadata, you definitely should contact the server administrator in any case. In practice, users blame the browser, not the server. Especially when using another (older) browser (that doesn't check the checksum) results in it working fine. The server administrator can then either fix the checksum attribute or the actual file. Or tell you to use another browser, because they don't have any idea what this checksum thing is, since they had paid someone to write the site and only later replaced the file being downloaded and aren't HTML experts... As a result, I wouldn't expect the false positive error to be the permanent state for important files. And the extra work required for the attribute should prevent it's usage for non-important files. I'd trust that casual content authors are too lazy to bother with it. The problem isn't casual content authors, it's authors who copy other people's pages and don't test with supporting browsers, or authors who got help from their geek Web designer daughter at Christmas and then later changed the file and broke it because they didn't understand it, or the case I referenced above where a company hires a Web designer to do the initial work and then later go and update it. Furthermore, the checksum attribute could be valuable against both memory corruption and network transfer corruption over unsecured (non-TLS) links. Of course, it wouldn't provide any safety against malicious uses. It doesn't really help against memory corruption, as discussed above. If network corruption is a concern, then TLS really is the way to go (I would expect network corruption to be more of an issue with an active attacker than passive hardware failure, and in the case of an attacker, they can just update the checksum too). In conclusion, it seems this proposal only solves a small problem, and doesn't solve it in a particularly successful manner. It's worth considering again if we have no more important things to address, but for now I haven't added it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Support of link rel=prefetch
On Tue, 27 Nov 2012, Laurent Perez wrote: I'm testing the prefetch attribute of link tags described at http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-prefetch I've only seen it work on Firefox desktop and mobile, on Chrome desktop, and on Android 4.0 stock browser. Mobile Safari, Opera, IE10 or Chrome for Android do not support it. Has this feature been abandoned because of lack of vendors interest? Abandoned by whom? You listed five browsers (using two browser engines) that support it. :-) I suspect further interest in this area is probably more likely to come in the shape of the prerendering feature, though: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035065.html http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037833.html Currently, only Chrome has indicated any interest in this feature. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Sortable Tables
I've added a feature to HTML to enable users (and authors) to sort tables. The basic design of the feature is that if a column's th has a sorted= attribute, the UA will sort the table every time the mutation observers would fire (before they fire). A table can have a sortable= attribute, which lets the user tell the user agent to add sorted= attributes to columns to sort them. On Tue, 6 Nov 2012, Ojan Vafai wrote: On Tue, Nov 6, 2012 at 11:25 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 1 Jul 2010, Christoph P�per wrote: For starters, only rows inside �tbody�s shall be reordered. For now columns don�t have to be reordered, ie. only vertical, no horizontal sorting. Done. Nevertheless the design should make it possible to add the other direction later. Well I guess nothing would stop us supporting sorted= on ths at the front of a row, but boy, that would be a lot more complicated to do. You'd have to be moving cells around all over the place. Not every table has content that makes sense to be sorted in a different order. So sortable tables should be marked as such. Note that �col� and �colgroup� elements are hardly supported. table sortable. Not every column has content that makes sense to be sorted in a different order. So non-sortable columns inside sortable tables should be marked as such. Any column with a th is sortable, for now. We can add a nosort column or something later if this becomes a problem. There are different ways to sort, eg. numeric, temporal or alphabetic and ascending or descending. Therefore columns should bear information how they should be sorted, ie. what kind of content their cells have. Ascending/descending is supported (sorted=reversed). Any temporal syntax supported by time can be used by putting time as the only child of the cells to sort. I intend to spec some sort of algorithm for doing numeric/string comparison, but haven't yet come up with a good solution. If you have any suggestions, this is the bug tracking this issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20524 Several columns may be used for sorting by some kind of priority. You can set sorted= on multiple columns' headers, and give a sort key cardinality in each, as in sorted=1, sorted=2, etc. The original order must be restorable. This I have not supported. I don't see how to support it sanely. Cell content may not consist of the string that should be used verbatim for sorting purposes, eg. leading articles or similar numbers with different units (�g�, �kg�, �t� �). Cells should have an optional attribute indicating their sort key. The �time� element already provides the necessary metadata features for temporal sorting � maybe there should be more of such elements instead. I've used data for this, alongside time. There may be columns that shall remain stable, eg. rank numbers. I haven't supported this. I've no idea how to do this sanely, especially given cells with column and row spans. 1. Would sorting actually reorder the DOM nodes or just change their visual order? It's not clear to me which one is better. I think the former is what you'd want most of the time. I've gone with reordering the DOM nodes. Things like :nth-child styling become nigh on impossible without doing it at the DOM level, not to mention the confusion that would reign from having such a dramatic disconnect between rendering and DOM (e.g. with abs pos, etc). 2. What values should the sort property allow. One idea is that it takes a JS function similar to what JavaScript's sort function takes. If you leave it out then it just does alphanumeric sort. I was going to have a comparator function, but I couldn't see a sane way to make it work in the face of hostile functions that mutate the DOM, so I dropped it. You can do custom sort orders by giving a key in the data element's value= attribute, though. 3. What elements does it go on? I don't see what it would do on a td. I could see putting it on a th though. Also, it's not clear to me what would get sorted. For example, in some tables, you would group trs inside tbodys and want to sort those. sorted= goes on a column-heading th, ideally in a thead but you can also put it on the first row of your tbody if you don't have a thead. Rows are sorted on a per-group basis. Rows that span each other are treated as one row for sorting. On Tue, 6 Nov 2012, Boris Zbarsky wrote: Another obvious question: how does (or should) sorting interact with rowspans? The sort algorithm groups rows that span each other together and treats them as one (using the data in their top row for sorting). On Wed, 7 Nov 2012, Silvia Pfeiffer wrote: http://tympanus.net/codrops/2009/10/03/33-javascript-solutions-for-sorting-tables/ Interesting, thanks. Also, a sortable table's header needed some indication of the sortability, so some
Re: [whatwg] Canvas: dash list API
On Sat, 22 Dec 2012, Anne van Kesteren wrote: Is there not some way we can have a lineDash attribute that returns a manipulatable object that inherits from Array rather than the current Java-like API? I remember this was discussed when getLineDash() and setLineDash() were added, but I think it's worth taking another look at this. (For URLs I want something similar for path segments and I'd rather not introduce get/set methods.) What would you want to have happen in the case of a library method that saves the context, sets the dash to an internal value, draws a line, saves the dash state to an internal value, restores the context, then returns? Should the caller, if they then grab the dashed line object from the context, get the internal value of the library? Should the restore() call mutate the saved dash object? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video feedback
On Thu, 20 Dec 2012, Jer Noble wrote: On Dec 17, 2012, at 4:01 PM, Ian Hickson i...@hixie.ch wrote: Should we add a preciseSeek() method with two arguments that does a seek using the given rational time? This method would be more useful if there were a way to retrieve the media's time scale. Otherwise, the script would have to pick an arbitrary scale value, or provide the correct media scale through other means (such as querying the server hosting the media). Additionally, authors like Rob are going to want to retrieve this precise representation of the currentTime. If rational time values were encapsulated into their own interface, a preciseCurrentTime (or similar) read-write attribute could be used instead. Ok. I assume this is something you (Apple) are interested in implementing; is this something any other browser vendors want to support? If so, I'll be happy to add something along these lines. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video feedback
On Thu, 20 Dec 2012, Mark Callow wrote: On 2012/12/18 9:01, Ian Hickson wrote: On Tue, 2 Oct 2012, Jer Noble wrote: The nature of floating point math makes precise frame navigation difficult, if not impossible. Rob's test is especially hairy, given that each frame has a timing bound of [startTime, endTime), and his test attempts to navigate directly to the startTime of a given frame, a value which gives approximately zero room for error. That makes sense. Should we add a preciseSeek() method with two arguments that does a seek using the given rational time? I draw your attention to Don't Store that in a float http://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/ and its suggestion to use a double starting at 2^32 to avoid the issue around precision changing with magnitude as the time increases. Everything in the Web platform already uses doubles. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video feedback
On Fri, 21 Dec 2012, Mark Callow wrote: On 2012/12/21 2:54, Ian Hickson wrote: On Thu, 20 Dec 2012, Mark Callow wrote: I draw your attention to Don't Store that in a float http://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/ and its suggestion to use a double starting at 2^32 to avoid the issue around precision changing with magnitude as the time increases. Everything in the Web platform already uses doubles. Yes, except as noted by Boris. The important point is the idea of using 2^32 as zero time which means the precision barely changes across the range of time values of interest to games, videos, etc. Ah, well, for video that ship has sailed, really. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Resource loading in browsing context-less Documents
On Wed, 19 Dec 2012, Boris Zbarsky wrote: On 12/18/12 3:25 PM, Ian Hickson wrote: Looking at the spec and at browsers more carefully, it seems that this is actually per spec (i.e. the spec says to follow the link). Does it say to do that if the ownerDocument of the a has no associated browsing context? What if it's not the currently active document? Firefox and IE do not check a checkbox from such a document when .click() is invoked on it, while WebKit and Opera do: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2032 However, when it comes to an a element with a target=_blank attribute in the same situation, only Opera seems to open the link: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2033 So I've put in a block on the handling of a (and area) elements specifically, making their activation behaviour nil if their doc doesn't have a browsing context (I didn't check if it has to be an active one). A similar block was present on form's submission algorithm. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Resource loading in browsing context-less Documents
On Wed, 19 Dec 2012, Boris Zbarsky wrote: On 12/19/12 12:11 PM, Ian Hickson wrote: So I've put in a block on the handling of a (and area) elements specifically, making their activation behaviour nil if their doc doesn't have a browsing context Does a document that is in something like bfcache or has otherwise been unloaded have a browsing context? Yes, just not an active one. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Submitting contentEditable Content In A Form
On Mon, 22 Oct 2012, Hugh Guiney wrote: On Wed, Oct 17, 2012 at 7:23 PM, Ian Hickson i...@hixie.ch wrote: I haven't added this, because contenteditable= is only truly useful with scripting enabled, and it's basically one line of script to support shunting the current value into a hidden input. For me, it's also useful even just as a way for blog contributors to edit the content of posts in-context (i.e., with styling applied, as it will appear on the final page, rather than blindly inside a textarea). Obviously it's going to be more versatile with scripting enabled, but that's true across the board, and contenteditable doesn't lose all value merely by virtue of the user not being able to add specific formatting: additional formatting could occur server-side (think Markdown expansion); a lot of content on the Web consists primarily or even exclusively of paragraphs; an editor could make purely grammatical, spelling, or factual changes to another user's article draft without touching the underlying structure... And the formatting isn't necessarily an issue anyway as UAs could just as easily add script-less controls, as they've done with the video element. That the attribute is currently useless with scripting disabled is the very reason I've brought this up; it would no longer be useless if there were a way to send its containing element's contents back to the server. How common is it for a part of a page to be editable when the page is loaded, for there to be no formatting UI, for the page to not mind if the user uses the browser's own formatting features (e.g. dragging and dropping formatted text into an editable region, using Ctrl+B, etc), and for the process of submitting the update to the server to consist of literally a form submission? I don't recall ever seeing a page like this. Literally every time I've seen contenteditable, it's had _some_ script beyond what is needed to shunt the value into a form control. If it's something that really does happen commonly, then sure, let's support it. Additionally, shunting into a hidden input, while perhaps trivial, is essentially a hack to work around this missing feature. As an author, it doesn't strike me as particularly intuitive when every other method of user-entry can be submitted on its own. Not every other. Anything involving drag-and-drop, for instance, requires script. What is the user benefit in making this particular method of data entry require an extra step? The benefit to _not_ having a feature is just that the platform is smaller, so we avoid all the costs associated with adding a feature: http://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94 This becomes especially more relevant when contenteditable is used for editors that don't just upload HTML; for example, the Google+ editor is contenteditable= but it's not going to upload the HTML, it uploads structured data. If the plaintext-only value is spec'd, that's no longer an issue: it could upload HTML by default, or plaintext when that value is set�which can obviously be transformed or subsumed into a structured data set, as G+ must do already. I don't understand what you mean. How would plaintext-only enable +mentioning and so forth to be handled without script? On Fri, 7 Sep 2012, Mikko Rantalainen wrote: The contenteditable attribute is meant for low level wysiwyg-editor like behavior framework and it is not meant to work standalone without scripting. Indeed. Why isn't it? What are the drawbacks? I'm not sure this question makes sense. Why is a bicycle not meant to have an engine? What are the drawbacks of turning a bicycle into a motorcycle? It's just the design that it has. It may be that there are use cases for a rich text editor that doesn't involve scripting, and in that case we should design and add such a feature; but that's orthogonal to contenteditable, which is specifically designed to be a low-level feature to enable people to write editors and so forth. I'd suggest supporting textarea type=text/html with a built-in HTML wysiwyg editor if any UA wants to support HTML editing without JavaScript. In that case, the UA should provide a scriptable method for detecting for native support of type=text/html. As a result, a CMS system could fallback to e.g. TinyMCE or CKeditor to emulate the missing support. This is actually what old versions of IE did (as htmlarea, IIRC), but it was dropped. I don't fully understand why, but I'm skeptical of introducing a new control for this without making sure we don't make the same mistakes, which means figuring out what those mistakes were. This is a little hard to search for with simple queries as there are a lot of results for DHTML scripts of the same name, but I did find the following article[1] which states that htmlarea premiered in version 5
Re: [whatwg] Resource loading in browsing context-less Documents
On Wed, 19 Dec 2012, Boris Zbarsky wrote: On 12/19/12 12:37 PM, Ian Hickson wrote: Yes, just not an active one. OK. I don't think we want to activate links in unloaded documents, personally That's probably reasonable... Do you have a test case? :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Standardizing Console object
On Tue, 18 Dec 2012, Rick Waldron wrote: Sent to: public-script-coord, whatwg (Please don't cross-post when posting to the WHATWG list; since it's a subscriber-only list, it results in fragmented threads when people not on the list reply to the thread.) Has there been any work or discussion with regard to standardizing the Console object? https://developers.google.com/chrome-developer-tools/docs/console https://getfirebug.com/wiki/index.php/Console_API http://msdn.microsoft.com/library/gg589530 http://www.opera.com/dragonfly/documentation/console/ http://developer.apple.com/library/safari/#documentation/appleapplications/Conceptual/Safari_Developer_Guide/DebuggingYourWebsite/DebuggingYourWebsite.html#//apple_ref/doc/uid/TP40007874-CH8-SW31 It's one of the specs on the TODO list: http://wiki.whatwg.org/wiki/Specs_todo Looking for volunteers! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Firing WebStorage storage event
On Wed, 3 Oct 2012, Janusz Majnert wrote: I would like to ask for your help. I'm having hard time understanding the rules for firing WebStorage's storage event. In section 11.2.3 (http://www.whatwg.org/specs/web-apps/current-work/multipage/webstorage.html#the-localstorage-attribute) we have this sentence [1]: When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did something, then in every Document object whose Window object's localStorage attribute's Storage object is associated with the same storage area, other than x, a storage event must be fired, as described below. as described below points to section 11.2.4, which reads [2]: The storage event is fired when a storage area changes, as described in the previous two sections (for session storage, for local storage). When this happens, the user agent must queue a task to fire an event with the name storage, which does not bubble and is not cancelable, and which uses the StorageEvent interface, at each Window object whose Document object has a Storage object that is affected. What I understood: Sentence [1] says that storage events should be fired on affected Document objects, except the one that originated the change. Sentences in [2] say that when a storage event is fired as described in [1], a task must be queued to fire storage events on all affected Window objects. It also says that Document objects have Storage objects, which I don't think is true. Is my understanding correct? What am I missing? This text was poorly written. I've fixed it. Thanks. Let me know if the new text is still confusing! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Details on window.open
On Sun, 7 Oct 2012, David Bruant wrote: I've been searching on the web for complete documentation about window.open and I have some unanswered questions. 1) what are the rules for popup blockers? Is every call to window.open blocked in modern browsers or are there exceptions? Per the spec, calls that would create a new browsing context are blocked unless called from the handler of a trusted 'click' event. (The spec also allows blocking in some other cases, and requires blocking in some sandbox cases, but those aren't popup-blocking-related.) I don't know if the spec is overly strict here; maybe it should also be possible on other trusted events e.g. mousedown or keydown? 2) About the third argument, is there a somewhat interoperable overlap in implementations or is it just an intricable mess? I haven't tried to spec it, because as far as I can tell, UAs could completely ignore it with no ill effects. If I'm wrong about this, then we should spec something. 3) Is what is returned a instance of Window or WindowProxy? By that I mean that if one browsing context A opens C and B window.open C too changing the URL (and reloading), is A supposed to have access to the new C or only the old browsing context? You can never get hold of a raw Window object, only WindowProxy objects. In your scenario, provided it's all same-origin, A will have an object that reflects that the browsing context has a new document loaded in it. (It's only one browsing context though.) 4) About step 4 of The rules for choosing a browsing context given a browsing context name [1]: If the given browsing context name is not |_blank| and there exists a browsing context whose name is the same as the given browsing context name, and the current browsing context is allowed to navigate that browsing context, and the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other, What does related enough mean? That's up to the UA. How is it implemented in different browsers? It varies. Gecko, IIRC, thinks everything is related enough. Chrome probably limits it to same-process windows. then that browsing context must be the chosen one. If there are multiple matching browsing contexts, the user agent should select one in some arbitrary consistent manner, such as the most recently opened, most recently focused, or more closely related. What is the consistent manner in each implementation? I do not know. I hope that this doesn't matter for interop; if I'm wrong, let me know and we shall spec it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Null characters
On Wed, 10 Oct 2012, Cameron Zemek wrote: On Wed, Oct 10, 2012 at 4:47 AM, Ian Hickson i...@hixie.ch wrote: I could add a note... based on what Boris described, what would you want the note to say and where would you want it placed, such that you would have seen it when your original reading caused you to e-mail the list? (This part of the spec is rather large, and the NULL handling happens all over the place, so I don't know where would be best.) I was thinking either in section 12.2.2 The input byte stream or 12.2.2.4 Preprocessing the input stream could mention the NULL character handling. Done. Thanks for the suggestion. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Canvas-related feedback
On Wed, 12 Sep 2012, Michael Day wrote: Yeah, that's why the spec hand-waves to transform the line too... but I agree that that doesn't really work. Do you have any suggestion of how to spec this better? This is the most general arcTo situation: setTransform(M0) lineTo(x0, y0) setTransform(M) arcTo(x1, y1, x2, y2, radius, ...) To generate the arc we need three points: P0, P1, P2, all in the same coordinate system. The three points are: P0 = inverse(M) * M0 * (x0, y0) P1 = (x1, y1) P2 = (x2, y2) We are transforming (x0, y0) by M0, which is the transform current at the time the point was added to the path. This gives us a point in canvas coordinates that we can transform by the inverse of M, which is the transform current at the time the arc is added to the path. This gives us a point in the same coordinate space as P1 and P2. In the common case where M = M0, the transforms cancel each other out and P0 = (x0, y0). Once we have the three points in the same coordinate space we can generate the arc and then apply M to all of the points in the generated arc to draw the arc in canvas coordinates. Does this make sense? I don't think it is possible to specify this process without requiring an inverse transformation somewhere, to get all three points into the same coordinate space. If so, it is probably best to describe this explicitly, rather than ambiguously implying the need for it. I think it makes sense, but I'd really rather not get into the nitty gritty of the maths if it can at all be avoided. I've tried to do as you describe, though. On Thu, 20 Sep 2012, Dirk Schulze wrote: On Sep 21, 2012, at 3:12 AM, Ian Hickson i...@hixie.ch wrote: The only situation that might be reasonable would be a transform on the Canvas that an author want to cover in the Path. But for the rare case where this matters, you can create a new Path object, add your path with the transform and call isPointInPath. Yeah, you could do that too. Furthermore, a transform() function that applies to a Path object seems to be useable as well. You can create a new Path, then add another Path to it while applying a transform, using the addPath() method. Yes, it is possible. But there are two reasons why I think that it still makes sense to use a transform function. First it seems natural to have a transform on Path object, like the CanvasRenderingContext2D already has. Both share a lot of functions, why disallow it for transforms? The main reason I didn't add it to Path is because it led to a bit of confusion in terms of what the transform applied to. Does it apply when you add points _to_ the path? Does it apply when you draw the path on another path or the canvas? Also, one of the more confusing aspects of the canvas API is that you can change the coordinate space while adding lines to the path, and we had a whole era wherein implemenations and the spec were confused as to what exactly happened when (did the points get transformed? Did the transform apply only when you stroke? etc). So in the new API I side-stepped the whole problem. Second, the solution that you mention requires a copy operation. A lot of libraries would create a new path, add the other path and apply the transform afterwards. Seems unnecessary for me. I don't really follow. Can you elaborate? On Fri, 21 Sep 2012, Rik Cabanier wrote: On Fri, Sep 21, 2012 at 2:12 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 20 Sep 2012, Dirk Schulze wrote: The interface of CanvasRenderingContext2D currently has a function called isPointInPath() with a Path object as input [1]. I wonder why this needs to be on the context interface. Wouldn't it make more sense on the interface of Path object itself? If an implementation really needs a context to get a point on a path it, it can create it on it's own. I don't think it would make _more_ sense, but I agree that it would make equal amounts of sense. In practice you're pretty much always going to have a context around when you want to check this, because the reason you'd use it is to see where I mouse click landed on a canvas. And you're going to want the Path object transformed as per the transform on the canvas, generally speaking. Not necessarily. The path object makes sense outside of canvas as well. You don't need a context to create it so we are thinking of integrating it with SVG. It would increase interop and simplfy the API's if you could ask SVG elements for their path, or create them with one. Sure, but with SVG you don't need to know if a point is in a path, because the events get dispatched to the right path by the UA. Maybe if there was a 'currentpath' property on the 2d context, you can move 'isPointInPath' to the path object. This would let you get rid of the extra 'isPointInPath' that takes a path too. so
Re: [whatwg] video feedback
On Tue, 2 Oct 2012, Jer Noble wrote: On Sep 17, 2012, at 12:43 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 9 Jul 2012, adam k wrote: i'm aware that crooked framerates (i.e. the notorious 29.97) were not supported when frame accuracy was implemented. in my tests, 29.97DF timecodes were incorrect by 1 to 3 frames at any given point. will there ever be support for crooked framerate accuracy? i would be more than happy to contribute whatever i can to help test it and make it possible. can someone comment on this? This is a Quality of Implementation issue, basically. I believe there's nothing inherently in the API that would make accuracy to such timecodes impossible. The nature of floating point math makes precise frame navigation difficult, if not impossible. Rob's test is especially hairy, given that each frame has a timing bound of [startTime, endTime), and his test attempts to navigate directly to the startTime of a given frame, a value which gives approximately zero room for error. I'm most familiar with MPEG containers, but I believe the following is also true of the WebM container: times are represented by a rational number, timeValue / timeScale, where both numerator and denominator are unsigned integers. To seek to a particular media time, we must convert a floating-point time value into this rational time format (e.g. when calculating the 4th frame's start time, from 3 * 1/29.97 to 3 * 1001/3). If there is a floating-point error in the wrong direction (e.g., as above, a numerator of 3002 vs 3003), the end result will not be the frame's startTime, but one timeScale before it. We've fixed some frame accuracy bugs in WebKit (and Chromium) by carefully rounding the incoming floating point time value, taking into account the media's time scale, and rounding to the nearest 1/timeScale value. This fixes Rob's precision test, but at the expense of precision. (I.e. in a 30 fps movie, currentTime = 0.99 / 30 will navigate to the second frame, not the first, due to rounding, which is technically incorrect.) This is a common problem, and Apple media frameworks (for example) therefore provide rational time classes which provide enough accuracy for precise navigation (e.g. QTTime, CMTime). Using a floating point number to represent time with any precision is not generally accepted as good practice when these rational time classes are available. That makes sense. Should we add a preciseSeek() method with two arguments that does a seek using the given rational time? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Feature Request: Media Elements as Targets for Links
On Sat, 24 Nov 2012, Nils Dagsson Moskopp wrote: Use Case Description: Linking to specific fragments of media is possible via media fragment URIs [1]. However, it is not possible to apply a link to embedded media declaratively, for example to link to a specific point in time for a media element on a page. [1] http://www.w3.org/TR/media-frags/ Basically, you're saying you have a Web page with a single major video or audio element in it, e.g. the YouTube watch page, and you want to be able to link to that page with a fragment identifier that causes the video to start playing at a particular time, without any scripts involved? Or is this just an internal-to-the-page thing? As in, you want to be able to, from within a page, cause a media element to seek to a specific time, in response to user interaction, without script? Or is relying on scripting ok? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] events when navigating away before page load?
On Fri, 14 Dec 2012, Mike Wilson wrote: What events are supposed to be fired when the browsing context gets navigated away before the current page has finished loading, ie before the load event has been fired? It's pretty complicated, but the short answer is beforeunload and unload. DOMContentLoaded and load don't fire per spec, though this is controversial (it's been suggested that the abort that happens during navigation should be equivalent to the abort that happens when the user hits Stop; whether it is or not changes whether or not we pretend that the page finished parsing or not). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] API for unique identification of devices (mobile/tablet/pc)
On Fri, 14 Dec 2012, Stan wrote: First, I don't think it's convenient for users to register themselves on many sites, which they visit occasionally. If most of the users do this right now, it does not mean they are happy with this, this is bacause there is no other, more simple way (as simple as just clicking on remember me). There are solutions to this problem, e.g. you can authenticate to a site using your Facebook identity using one or two clicks. Second, user accounts are based on e-mails as a rule, which is not unique at all, every user can have multiple e-mails and multiple registrations. Many web-services struggle against users' reputation spoofing made via such fake accounts. Users can have multiple devices and could tell their browser to provide a unique identifier with each page access, so a device ID API wouldn't stop or change this. Third, I think it's up to a certain web-service design and requirements, if it needs to identify user accounts or user devices. For example, usage of the same profile on multiple devices can be a violation of a web-service license agreement, or a web-service may bind several devices to the same profile. Binding multiple devices to a profile is easy and done today, it doesn't require an identifier. An identifier wouldn't help stop a user from using multiple devices with one site (not that such a restriction would even make sense in the first place), because there's no guarantee that the user agent isn't providing you with fake device identifiers. Multiple browser profiles on the same device do not matter, because the same device ID will be returned. What if the different profiles are for different people? Or different identities of the same person? (e.g. a woman's professional identity and a pseudonymous identity in an assault support group; or a man's identity that he uses for this extended family, and his identity that he uses when exploring his transexuality?) The main point, if device ID could be available it would provide more great possibilities for users and web-services. I don't understand what it would provide that would be better than the existing ability to use one's identity from an identity provider. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] API for unique identification of devices (mobile/tablet/pc)
On Fri, 14 Dec 2012, Stan wrote: Last thing to remember: the device ID is not something secret and forbidden for native applications. For example, Android provides Android ID and iOS ASIdentifierManager, which can be read by any installed application. Taking into consideration that many web-services do provide native clients, they already know device IDs (if they want to). Moving this property into browser will just simplify developing web-applications and make them more competitive compared to native apps. That the Web is more secure and privacy-protecting than native apps is one of the Web's biggest strengths. It's a feature, not a bug. It makes the Web more competitive, not less. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] events when navigating away before page load?
On Fri, 14 Dec 2012, Mike Wilson wrote: Anyway, the finding that originally got me started on looking at this was that I received an unload event without a preceeding load event. Naively this seems logically wrong, but I appreciate these are complicated matters so I'm content with the answer that this probably shouldn't be expected in these kinds of cases. Yeah, this whole area is rather gnarly. As a general rule, the intent of the spec is that you get a load when all your scripts (and other resources) have loaded, and you get an unload when the page is going away. Thus if the page goes away before the page has finished loading, you just get an unload. We additionally also suggest firing a load and so forth when the user aborts the page, on the assumption that you probably have all the scripts you need and are only missing minor things like ads or analytics, but that doesn't apply when the page is aborted because another page is going to replace it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Feedback on a variety of elements
it. No manipulation involved. For srcset=, it's at most a concatenation of a few strings. When would you _parse_ it? Should we cite examples of sites that grab/manipulate the value of an img tag’s src? If it's more than just toggling between images, yes. I would definitely like to know when srcset= is going to be parsed, because without knowing what the use cases are, it's impossible to evaluate the proposals to solve them. It is possible to address this by repeating the same image at a larger breakpoint, like: img srcset=800.jpg 1x 1599w, 1600.jpg 2x 1599w, 1600.jpg 1x However, this means you're duplicating data, and have a chance of failing to update all of the urls when you update one. It also becomes more hostile as future screens arrive with higher resolutions. For example, if 3x screens showed up, one would have to write the following to serve things in the most ideal manner: img srcset=800.jpg 1x 1599w, 1600.jpg 2x 1599w, 2400.jpg 3x 1599w, 1600.jpg 1x 2399w, 2400.jpg 1.5x 2399w, 2400.jpg 1x At this point it's just silly, and very error-prone. I agree, when there's 3x displays, this could get to the point where we need to solve it. :-) With the current displays, it's just not that big a deal, IMHO. Perhaps we should skate to where the puck will be, rather than where it is now. If we knew where the puck was going to be, I'd be all for that. The risk, however, is making elaborate solutions that have high costs (see the earlier link) but that never pay off, because the puck suddenly veered in a different direction than what we guessed. On Thu, 11 Oct 2012, Markus Ernst wrote: My point is, that any device-specific notation, such as 2x, forces the author to make decisions that the browser should actually make. The author does not know if in a few years the image will be viewed with 1.5x or 3x or 7x or whatever devices. No, but the author does know what pixel density the image has. This is why I'd humbly suggest to put information on the image in @srcset rather than info on the device and media. Such as: srcset=low.jpg 200w, hi.jpg 400w, huge.jpg 800w Where 200w is the actual image width and not the viewport width. Like that every browser can decide which source to load based on the display, and available bandwidth or user setting or whatever. The problem is that the image's width doesn't help the user agent at all. How is the user agent supposed to know which image looks best on a 600 pixel wide viewport? The image could be intended to be a small icon inline in the text, or a sidebar full-bleed image, or a photograph in the main flow of the text. I just don't see what the UA can do here. On Sat, 13 Oct 2012, Fred Andrews wrote: This does seem to be an important point. Would the follow be a correction understanding of your point: if there are a range of images each with a different declared size and the CSS pixel size of the image is not constrained then the browser must use the image pixel size to determine the CSS pixel size and without knowing the density then this can not be done uniquely? I don't really see how this could work. Perhaps the 1x density image could be placed first in the list, and then the densities would all be defined. That assumes the images are the same width, which doesn't handle the art use case, where the author wants a cropped image on a cell phone screen but a wide shot on a tablet. On Fri, 19 Oct 2012, Fred Andrews wrote: If it is really necessary to support this case then perhaps both the image width and the the native pixel breakpoints could be specified in the srcset. Then srcset=low.jpg 10w 20w, hi.jpg 20w 40w, huge.jpg 30w would mean: low.jpg is 10 pixels wide and use it if the native pixel width of the image box is less than or equal to 20, hi.jpg is 20 pixels wide and use it if the native pixel width of the image box is less than or equal to 40, huge.jpg is 30 pixels wide and use it if the native pixel width of the image box is less than greater than 40 pixles The default break points could be the image sizes, and would typically not be needed. The first image could be the 1x density image, allowing the browser to determine the image box size if not otherwise specified and this could be done before loading the image. This approach may be more natural for a fluid design. Given how people are complaining that srcset= is complicated as it is, making it even worse doesn't seem like a winner to me. :-) On Fri, 2 Nov 2012, Eric Portis wrote: On Tue May 15 00:28:54 PDT 2012, Ian Hickson wrote: In practice, the only information regarding dimensions that can be usefully leveraged here is the viewport dimensions. This isn't the end of the world, though -- there's often going to be a direct correlation between the dimensions of the viewport and the dimensions of the images. This relationship
Re: [whatwg] events when navigating away before page load?
On Sat, 15 Dec 2012, Olli Pettay wrote: There are also pageshow and pagehide events, although the spec for them seems to be wrong. They are fired always, not only when dealing with session history. Do you have a test case that shows when they are fired in a way that doesn't match the spec? (Note that session history is invoked when you load a page, and that pagehide is fired in the unload algorithm as well.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why do HTML*Collection's nameItem need to return 5 different objects?
On Thu, 6 Sep 2012, Simon Pieters wrote: On Wed, 05 Sep 2012 22:47:07 +0200, Ian Hickson i...@hixie.ch wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1736 Webkit returns undefined, whereas IE, Gecko, and Opera all return an HTMLCollection. (IE returns an HTMLCollection with a tags() method, Gecko and Opera do not. The spec requires an HTMLAllCollection, which is the kind of collection that has a tags() method in the spec; in IE, all collections have a tags() method, and document.all is actually a regular HTMLCollection. We could change the spec here, e.g. to put tags() on all collections or to just forget about tags() on the subcollection here.) I thought we had agreed to drop tags() everywhere except for the document.all collection. I guess the collection returned by document.all.foo wasn't discussed back then, though. Opera and Firefox don't support tags() there, which suggests it's not needed for compat, so maybe the spec should side with Opera/Firefox and return HTMLCollection instead of HTMLAllCollection. Ok, I've made document.all.foo return an HTMLCollection. On Thu, 6 Sep 2012, Ojan Vafai wrote: On Wed, Sep 5, 2012 at 1:47 PM, Ian Hickson i...@hixie.ch wrote: For HTMLOptionsElement, the situation is more murky. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1739 From what I can tell, IE doesn't do direct named access, you have to do it via item() or namedItem(). The spec didn't support item() access for names, though all the browsers did. I've filed a bug on DOM Core for that. Using namedItem(), you see that IE returns a live HTMLCollection, the spec returns a live NodeList, WebKit returns a static NodeList, and Opera and Firefox return just the first option. (There's a note in the spec asking if we should switch to HTMLCollection rather than NodeList.) I haven't followed the details closely enough to know which APIs should be returning which types of lists/collections. As a general point though, anywhere we can avoid live NodeLists/Collections is a big improvement. They impose a significant implementation cost both in terms of complexity and in terms of performance impact. Ok, I've changed to match Opera and Firefox on this one, since that was the least complex solution. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] API for unique identification of devices (mobile/tablet/pc)
On Thu, 13 Dec 2012, Stan wrote: The reasoning for this API is the need to uniquely identify every device in many web-applications. Why do you need to identify the device? What about if the user uses the same browser profile on multiple devices? Or multiple browser profiles on the same device? Or moves their profile from one device to another? Or uses multiple virtual machines in one device? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Question on Limits in Adaption Agency Algorithm
On Wed, 12 Dec 2012, Henri Sivonen wrote: On Sat, Dec 8, 2012 at 11:05 PM, Ian Hickson i...@hixie.ch wrote: the order between abc and xyz is reversed in the tree. Does anyone have any preference for how this is fixed? Does it need to be fixed? That is, is it breaking real sites? It reverses the order of text nodes. That's ridiculously unintuitive. Yes, I think it needs solving, even if it isn't hit by any sites. (If it's hit by sites, it seems likely that they are breaking because of it. If it isn't, then we can safely change it regardless.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
On Wed, 12 Dec 2012, Rik Cabanier wrote: What would be the next step? Should we define a new version of drawImage with the extra parameter? At the WHATWG, the process, insofar as there is one, is that the spec's editor (in this case me) goes through the e-mails on a topic and edits the spec based on the feedback and based on how much vendor buy-in an issue has. On this particular topic, I've only heard interest in implementing this from one vendor, Google, so adding support to the spec at this point is probably premature. If other vendors are interested in implementing something for this (a feature to make drawImage scale subsets with clamping at the source rectangle rather than the original image), I encourage them to indicate this on this thread. If so, we probably want the description of the existing drawImage call to change so it leaves the resampling issue undefined unless WebKit is OK with changing their current behavior. Leaving the spec undefined is not acceptable. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas in Workers
On Tue, 11 Dec 2012, Gregg Tavares (社�~T�) wrote:
discussion seems to have died down here but I'd like to bring up another
issue
In WebGL land we have creation attributes on the drawingbuffer made for a
canvas. Example
gl = canvas.getContext(webgl, { preserveDrawingBuffer: false });
We're working out the details on how to set those options for the case
where we have 1 context and multiple canvases.
The particular option above would apparently be a huge perf win for
canvas 2d for mobile. Which suggests that whatever API is decided on it
would be nice if it worked for both APIs the same.
What does it do?
In the 2D canvas, whenever you bind to a new canvas, the context is reset
to its default state, the context's hit region list is reset, and the
context's bitmap is reset. The next time the context is flushed, the
canvas itself is always reset (since flushing the context causes the
bitmap and hit region list to be pushed to the canvas, replacing whatever
was there before).
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] metadata attribute for media
On Thu, 20 Sep 2012, Ralph Giles wrote: Back in June, I proposed[1] a new attribute to get metadata tag data out of media resources. I've done an experimental implementation of this which is now in the Firefox Aurora (alpha) channel[2] and Nightly development builds. The method is media.mozGetMetadata() and it returns a new object each time, whose properties are key:value pairs representing the metadata tags from the file. Aurora supports this for Ogg Vorbis (.ogg) streams. Nightly supports Opus (.opus) files as well. Right now the method returns whatever set of tags happen to be in the media stream, at least if they can be interpreted as unicode text. There are several things I'd like to fix about this. Media formats generally have rules about how to map various tags to a standard vocabulary. Right now, web content has to implement those rules, but the user-agent is in a better position to do so. Also, a number of Mozilla (C++) developers I've talked to prefer a fixed schema for metadata, rather than the more dynamic approach. So, I'd like to do a new method which returns an object with a fixed schema we can describe in idl, representing standard fields derived from the dublic core tag set. The raw metadata would be available under the old method for advanced applications. Some metadata is also per-track, rather than per-stream, so it makes sense to have these calls available on track objects as well as media objects. The most essential tags are dc:creator and dc:title. That covers almost all player use cases. For per-track metadata, the language is perhaps also useful for selection purposes. Are there any other tags folks would like to see in the initial proposal? [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-June/036352.html [2] available from aurora.mozilla.org This seems reasonable. If there's implementor interest from other vendors, and if there's a spec that I can point to for how to get the metadata out of the various formats, then I'd be happy to add it to the spec. I don't want to be the one to maintain the mapping from media formats to metadata schema, because this isn't my area of expertise, and it isn't trivial work. I don't think we should have an open-ended API without fixed names, because that is a recipe for an interoperability disaster. We'd just end up having to define the mapping later when major yet poorly-tested sites started depending on particular mappings of popular UAs. On Mon, 26 Nov 2012, Ralph Giles wrote: On 12-09-27 1:44 AM, Philip Jägenstedt wrote: I'm skeptical that all that we want from ID3v2 or common VorbisComment tags can be mapped to Dublin Core, it seems better to define mappings directly from the underlying format to the WebIDL interface. You're right. Indeed. Given the open-endedness of metadata contained in actual media resources, I'm personally a bit skeptical that there's something we could add to the Web platform that would be better than just letting authors pass that metadata out-of-band using any representation they like, but what use cases are you trying to cover here? Two use cases I'm trying to address: - A web application presents some view of a media library. If the libray resides on a server, then yes, the server-side component of the app can parse, cache, and deliver the metadata out-of-band. But the library could also be local, in which case the webapp must do its own parsing, e.g. from a list of blob urls returned by the file api. - An author wants to display the embedded track title and artist name with simple scripting on a webpage. For music in particular this seems reasonable. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
at boundaries, especially visible when tiling. * clamping to source image bounds can cause color bleeding artefacts when rendering a sprite from a spritemap. Right. The second is easy enough to work around by having some empty pixels (not ideal, but then neither is scaling sprites, really...). The first has no work around that I'm aware of, so if we don't have a flag, it should be the one we support. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fwd: fallback section taking over for 4xx and 5xx responses while online
On Fri, 24 Aug 2012, Josh Sharpe wrote: I have a manifest that looks something like this: CACHE MANIFEST # e4a75fb378cb627a0d51a80c1cc5684c2d918d93e267f5854a511aa3c8db5b1a /a/application.js /a/application.css NETWORK: * FALLBACK: / /offline Notably, it has a / /offline fallback section which is, obviously, a prefix for every page on my site. This is good, because the goal is to have my users redirected to what's at /offline when they navigate to www.mydomain.com while offline. Note that the Offline Application Cache feature is for Offline Applications, not Offline Sites. What you're trying to do here is not what appcache was designed to do. Also, it's not clear what you mean by offline. For the record, in the spec, offline includes I'm on wifi but there's a captive portal and I'm online but the server is broken. As the fallback section is a prefix for everything, it's a prefix for any url/path that results in an error condition such as a 404 or 500 response. These are cases where it's assumed that the server is broken, i.e. offline, and the cache is therefore used. It seems that the application cache, when it encounters an error state such as a 404 or 500, doesn't check to see if the browser is still in the 'online' state, and immediately falls over to the fallback section. It does check -- by definition, if it receives a 4xx or 5xx, it's assumed that the server is offline (broken). While online, I would expect my 4xx and 5xx page to be rendered normally. Offline Application Cache doesn't have a while online mode, it just always works as if you were offline and tries to get the data from the server while the server is able to respond. This is an important facet of how appcache works: it doesn't work online or work offline. It always acts in offline mode (or rather, always works in internet connection is flaky mode). Finally, the fallback section in my example is very typical of most examples I find in various docs, including the whatwg spec. I don't think I'm doing anything abnormal here. What's abnormal is having the user visit pages that return 4xx or 5xx error codes when there's no problem. :-) Should I design this differently or is there something missing from the spec? It's hard to know exactly without understanding more about your use case. Can you elaborate on what you're trying to do? We could just exclude 4xx (and maybe 5xx? Though that seems less reasonable) error codes from being considered offline for fallback- supported resources, if people are commonly linking people to missing pages intentionally (and don't want the problem hidden from users by having it fall back to locally-generated pages). But that seems like a weird thing to do... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for public data in drag events
On Thu, 30 Aug 2012, Trevor Burnham wrote: The main use case I have in mind is an interface where elements respond to the object being dragged. A common case is showing visual feedback depending on whether the element emitting a dragenter/dragover is a valid drop target for the object being dragged. Currently, this can only be done in response to the types attribute. Right, that's what the type is for. Using global state in tandem with the types attribute is a viable workaround for drags within a document, but an inelegant one. Indeed. The types are supposed to be the solution here. If something is a valid thing to drop, it should have a type that can be accepted, and vice versa. Are there use cases where this doesn't work somehow? It's also incompatible with multi-touch. Although no multi-touch implementation of the dnd spec currently exists (to my knowledge), the spec does not preclude multiple simultaneous drags, so this may be a concern in the future. On Thu, 30 Aug 2012, Bronislav Klu�~Mka wrote: If you want example of cross window, I can give you one, I was working on administration, where certain information were presented using the same DOM constructions but they can be inserted/placed in different views so I've created the application as a set of iframes. But while using DD I've run into similar problem (I had a treeview of categories and certain data from another iframe can be copied/moved to certain nodes, not every data to every node), I had to solve it by putting data information in drag data item type... Being able to access some complex data in e.g. dragover event would be peachy Could you elaborate on this? What information would you use in the dragover event that isn't just a type label? It seems to me like you'd just use the category as part of the type and then the datagrid would accept certain types in certain places. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] gradient edge case
On Sat, 1 Sep 2012, Rik Cabanier wrote: Currently the canvas spec specifies the following: If x0 = x1 and y0 = y1, then the linear gradient must paint nothing. and If x0 = x1 and y0 = y1 and r0 = r1, then the radial gradient must paint nothing Why is this? At this point: it's what browsers (mostly) do. On Sat, 1 Sep 2012, David Dailey wrote: While on the topic, it seems like reflected linear gradients would be quite handy -- insert an edge into the stop-sequence and then reflect or repeat from there. Can't you just do that by listing the colours forwards and backwards? On Sat, 1 Sep 2012, Rik Cabanier wrote: Since Canvas has support for pattern, you could fairly easy emulate this behavior. I think it would be handy if you could add the 'reflect' idiom to patterns. Can't you just make the larger pattern and use that? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Quirks mode handling of rowspan=0
On Sun, 2 Sep 2012, Boris Zbarsky wrote: Per HTML5 spec, rowspan=0 should span to the end of the table section. WebKit seems to not implement this at all. Opera implements this in quirks and standards mode. Gecko implements this in standards mode only; in quirks mode, rowspan=0 is treated like rowspan=1. When we last tried to do the right thing in quirks mode, back in 2003 or so, we ran into site compatibility issues, hence the current setup. I don't know what Trident does here; worth testing. In any case, my suggestion is that in quirks mode, rowspan=0 not be supported. On Mon, 3 Sep 2012, Kang-Hao (Kenny) Lu wrote: IE seem to follow WebKit in every mode I tested with. (i.e. not support) On Thu, 6 Sep 2012, Simon Pieters wrote: greping for rowspan=\0\ in http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-data-for-the-masses/ and http://dotnetdotcom.org/ I find the following pages being broken in Opera but working in Firefox/Chrome: http://www.persianv.com/ http://www.quicherchetrouve.be/index.php?r1=2an=3anb=239page=3 http://www.kvaak.fi/keskustelu/index.php?topic=1914.0 http://www.timekillerarcade.com/game.php?id=1941 http://www.elginisd.net/cgi-bin/calcium37.pl?CalendarName=David_SchmittOp=ShowItAmount=WeekNavType=BothType=ListDate=2008/8/1 I stopped after going through about half of the matches. All of these are quirks mode. I didn't find any that work in Opera/Firefox but are broken in Chrome (i.e. rely on it being unsupported in standards mode). I didn't find any that work in Opera but are broken in Firefox/Chrome (i.e. expect it to work in quirks mode). This is enough to convince me that the feature should not be supported in quirks mode. Done. On Mon, 3 Sep 2012, Jukka K. Korpela wrote: Generally, attempts at defining quirks mode would mean making it an alternate mode and will not be successful due to the wide variation across browsers and versions. It's called quirks for a reason. We have indeed created an alternate mode (two, actually). See the HTML spec, search for quirks. Specifically, as some browsers already support rowspan=0 in quirks mode, and some don't, you cannot ensure backwards compatibility no matter how you define it. Depends if UAs are willing to change quirks mode. By and large, they are. On Mon, 3 Sep 2012, Boris Zbarsky wrote: Yes, it does: once all browsers agree, the barrier to entry for new entrants is lower because they just need to implement the behavior everyone already agrees on. That's the dream! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Autocomplete and autofill features and feedback thereon
On Wed, 21 Nov 2012, Ilya Sherman wrote:
On Tue, Nov 20, 2012 at 5:17 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 16 Oct 2012, Ilya Sherman wrote:
The payment instrument type is almost certainly appropriate to add
-- it is included on almost every website that I've encountered that
includes payment card fields. It was an oversight on my part to
omit it from the initial proposal.
It's redundant data, the credit card number itself says what type it
is.
More importantly, I don't know how to store the information. What
values should we be expecting here? If a site has radio buttons v,
m and a, and another has a select with 4, 5, and 3, and
yet another has three buttons which set a type=hidden with the values
visa, mastercard and amex, how is the user agent to figure out
what's going on? This makes the magic needed around dates look
positively easy.
I agree that it's redundant data, but many websites ask for it
separately anyway. One common reason for this is that the website only
supports a subset of all possible credit card issuers -- for example,
many do not support DiscoverCard. While the site *could* theoretically
infer from the entered card number that the card is not supported, and
show the user an error, most sites instead force the user to select the
card type, and inform the user of unsupported card types by omitting
them from the list.
Regarding storing of the data: I think being able to fill the data is
more important than being able to store it. For example, Chrome stores
just the card number, and not the type; but Chrome supports filling the
type by inferring it from the stored card number. For filling the card
type, I think it's strictly easier than filling a select dropdown
containing country names, since localization issues don't come into play
as much. The user agent is presumably not going to be able to handle
*every* case; but in my experience, it's not too hard to handle
many/most of the real-world cases. Since this attribute is used just as
a hint, esoteric difficult cases don't seem like enough reason to omit
the card type as a known token in the spec.
Fair enough. Added.
Finally, I have gotten a request to include a field type for bank
account numbers, though I have only seen this info actually
requested on a small handful of extremely prominent (and generally
trusted) websites: Amazon, PayPal, and I think Google Wallet.
Is there any reason we shouldn't just treat bank accounts like just
another credit card, and use cc-number for these?
Yes: Most websites that support credit card numbers as inputs do not
support bank account numbers. The few websites that do support bank
account numbers use separate fields for these vs. credit card number
inputs. Labeling both fields identically would leave the browser unable
to distinguish which field to fill with what info.
Fair enough. So what do you need for bank account information? Account
number? Account holder name (and subproperties for that like for cc-*)?
Routing transit number? IBAN? SWIFT-BIC? I hesitate to do something US-
specific here; what do sites ask for in other countries? If it's always a
name, a bank number of some sort, and an account number, I can add those
three fields (plus the two name subfields) pretty easily.
On Wed, 31 Oct 2012, Dan Beam wrote:
The experimental implementation [1] has been updated to dispatch an
autocompleteerror as per convention/your feedback.
autocompleteerror seems like it'd be fired for an error, not user
cancelation. User cancelation is usually called either abort or
cancel. I think autocompletecancel is fine. It's consistent with
oncancel, which we used for dialog. (Fullscreen's error event is
for a slightly different case, based on what the spec says.)
There are also cases where we'd want to return actual errors. For
example, in Chrome, we are only planning to support this dialog for
sites served over HTTPS and without security errors. We might also want
to fire an error in case the input fails to pass the form's validation
requirements. Should we use autocompleteerror for the errors, and
autocompletecancel for user cancelations? Firing separate events for
cancelations vs. errors forces developers to check for each of these
cases separately, which seems like a less convenient API than just
checking for one sort of failure event. Perhaps we should have a single
event named something like autocompletefail or something like that?
autocompleteerror is fine.
On Wed, 21 Nov 2012, Dan Beam wrote:
I definitely agree to a single event. It would be great to do this and
give enumerable failure reasons (if this is deemed secure enough).
An example:
enum ErrorCause {
FROM_FRAME,
NEEDS_GESTURE,
NOT_SECURE,
};
This could be a property on the event (event.cause, event.reason?)
argument
Re: [whatwg] gradient edge case
On Mon, 10 Dec 2012, Rik Cabanier wrote: yes, however it will be slower since the pattern has to be rendered two or four times. If you can reflect in x and y, you can calculate the pattern cell once and then have your hardware do the tiling. If it's something that happens a lot, then certainly it makes sense to add it. But I've heard very few requests for this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Autocomplete and autofill features and feedback thereon
On Mon, 10 Dec 2012, Ilya Sherman wrote: On Mon, Dec 10, 2012 at 7:49 PM, Ian Hickson i...@hixie.ch wrote: Finally, I have gotten a request to include a field type for bank account numbers, though I have only seen this info actually requested on a small handful of extremely prominent (and generally trusted) websites: Amazon, PayPal, and I think Google Wallet. Is there any reason we shouldn't just treat bank accounts like just another credit card, and use cc-number for these? Yes: Most websites that support credit card numbers as inputs do not support bank account numbers. The few websites that do support bank account numbers use separate fields for these vs. credit card number inputs. Labeling both fields identically would leave the browser unable to distinguish which field to fill with what info. Fair enough. So what do you need for bank account information? Account number? Account holder name (and subproperties for that like for cc-*)? Routing transit number? IBAN? SWIFT-BIC? I hesitate to do something US- specific here; what do sites ask for in other countries? If it's always a name, a bank number of some sort, and an account number, I can add those three fields (plus the two name subfields) pretty easily. I honestly haven't done enough research to answer these questions. I was mostly including this type for completeness, since several people mentioned it to me in offline discussion. However, since I'm not aware of any browsers that currently support or are planning to add support for autofilling bank account numbers, and I'm only aware of a handful of websites that request them, I'm ok with punting on this for now. Ok, sounds good. If someone else has done the research and thinks it would be valuable to add this type to the spec, please do post here. Indeed. I'm happy to add this if browser vendors want to support it and we have good data on it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Question on Limits in Adaption Agency Algorithm
On Sat, 3 Nov 2012, Yasuhiko Minamide wrote: This is about Adaption Agency Algorithm in 12.2.5.4.7 The in body insertion mode. Limits of loops in the adoption agency algorithm were introduced in http://html5.org/tools/web-apps-tracker?from=5641to=5642. However, the limit for the inner loop introduces an unexpected behaviour for the following fragment of an HTML document. biasttdiv/babc/b/div/tt/s/axyz/i This document is parsed into the following DOM tree. b i a s tt/tt /s /a xyz /i /b a s tt div b/b abc /div /tt /s /a xyz is inserted as a child of i and the order between abc and xyz is reversed in the tree. We would like to know whether this is an intended behaviour of the specification. Yeah that's definitely not intentional. Does anyone have any preference for how this is fixed? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Controlling the UI on input type=date
On Thu, 6 Dec 2012, brenton strine wrote: It is currently difficult to control the visibility of the UI (e.g. little arrows, spinners, etc) on new input types like datetime, number, range, color, etc. The idea is for Web Components or XBL or some such solution to be the solution to this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Making cross-origin iframe seamless= (partly) usable
On Wed, 5 Dec 2012, Jonas Sicking wrote: It seems to me like the best solution is to have a new HTTP header, with the four following values being allowed: Seamless-Options: allow-shrink-wrap Seamless-Options: allow-styling Seamless-Options: allow-shrink-wrap allow-styling Seamless-Options: allow-styling allow-shrink-wrap I guess it depends how costly you think it is to mint new HTTP headers rather than having fewer, harder working headers. I hear no end of people arguing that HTTP headers are too hard for people to use. Could we make these settable through meta elements as well as, or instead of, using headers. The problem is that we need to have the information before we create the Document, since once the Document is created the page might be rendered, and if the information comes after the Document is rendered, there would be flicker (different sizes for the iframes, different styles in the iframes). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Make the files attribute of the input element writable
On Wed, 5 Dec 2012, Victor Costan wrote: There was a thread on this mailing list discussing making it possible to set the file data behind an input type=file element. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/thread.html#36140 The thread seems to have died down due to insufficient applications for the proposal. Actually the reason this thread hasn't gone anywhere is that there seems to only be implementer interest from Chrome. See: http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest 1) This would make it possible to write JavaScript libraries that seamlessly scan the current page for input type=file and add integration with Dropbox / Google Drive / Sky Drive etc. I claim that changing the input value is the easiest and most robust method of achieving this without requiring changes to the main application code. Asides from providing an easy path for developers to integrate online storage services into their apps, this change would make it easy to write bookmarklets / browser extensions that add this functionality to any Web application. It seems like this use case would be better handled by having the sites offer an API to the browser, similar to Web Intents, for picking a file. That way you wouldn't need to update each site -- every site would support all the drive systems you use. 2) If I can set the files attribute of an input type=file, I can write unit tests for any code that deals with such an input, such as XHR uploads. Tested code is less likely to break down as it is maintained, so it makes for a better Web. That's an interesting use case, indeed. 3) Browser extensions / bookmarklets could easily filter files being uploaded. For example, an extension could automatically resize pictures larger than a certain threshold by rendering them to an off-screen canvas. As another example, an extension could detect when huge files are uploaded to a Web mail client or forum, automatically upload them to Dropbox / Google Drive / Sky Drive, and replace them in the input type=file with tiny .url files pointing to the real files. In general, browser extensions don't have to be handled by Web standard APIs, so I'm not sure that's a compelling use case. With these applications in mind, I don't think FileList needs to accept Blobs. Instead, there should be an easy way to build a File out of a Blob and a file name. This capability seems to have been lost when BlobBuilder was deprecated by the Blob constructor. There are places where FileList definitely needs to be readonly, so I don't think it makes sense to make it globally writable. but there could be a MutableFileList or something. That feedback should be sent to the list mentioned at the top of the File API spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: allow itemid to record multiple identifiers for an item
On Wed, 5 Dec 2012, Ed Summers wrote: Was the id itemprop you used in your examples a hypothetical property that would need to be defined at schema.org or elsewhere, or did you find it defined already? Hypothetical. In the schema.org vocabulary, the existing url property could be used, maybe? Or a new one, of course. I couldn't quite tell from the schema.org documentation if url was intended to do this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] seamless iframes and event propagation
On Wed, 5 Dec 2012, Anne van Kesteren wrote: Ian, for HTML that would allow easily dealing with the load exception on Window too. The load exception is weirder than that. It's target is different than the element that ever gets the event. Unless you mean the other exception, in which case, possibly, yes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Specification unclear about how HTMLElement.prototype.onscroll's getter/setter should behave for body elements
On Tue, 4 Dec 2012, Peter Van der Beken wrote: On 04/12/12 01:33, Ian Hickson wrote: onscroll is a case where there's really no reason to use a different setter, agreed. So I've commented that out (and it's similar friends). That still leaves onerror though. The same change should probably be done to HTMLFrameSetElement. Good catch. Fixed. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [mimesniff] Sniffing archives
On Tue, 4 Dec 2012, Gordon P. Hemsley wrote: To be more specific: (1) Safari doesn't appear to prompt the user for any downloads. It just automatically downloads any file it can't handle. (2) If you allow Safari to open safe files that it downloads, ZIP appears to be one of them. Gzip and RAR, however, do not. So this isn't the most convincing argument. In particular, it doesn't seem like this needs to be defined in the MIME sniff spec. There's no harm in the browser sniffing more non-scripted types than the spec says, if it's just for labeling or handling at the OS level. It's when one browser handles something as completely safe and another handles something as live, or when a browser displays a file differently than another browser, that there's a problem, really. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Menus and Toolbars
On Thu, 29 Nov 2012, Olli Pettay wrote: I think we need to keep the contextmenu functionality, and I don't see reasons to not to do it the way Gecko has it now (using menu type=context and menuitem). Do you mean as opposed to allowing menuitem to refer to commands declared elsewhere in the spec? The main advantage of command= is that it allows a context menu (or toolbar menu, or anything else if we start adding command= to other elements like button or something) to define a command in one place, and then refer to it other places, so that an author can e.g. disable it in one place and have all the UI update. I think that's pretty useful. Is this not something Gecko will implement? (It's based on XUL...) I'm also still hoping from input from Safari, Opera, and IE regarding what kinds of stuff would be acceptable to implement here. type=button might be nice. Some feedback that was raised on IRC was that it might make more sense to have a button type=menu that, when clicked, shows the contextmenu=. Or a button type=menu menu=... that uses the designated menu. Or button type=menu Label menu type=context.../menu /button or some such. The idea being that it's easier to style a button to work like a menu button than to style the menu element itself, since you really want the menu element to be styled as part of being the actual menu part. In Gecko MenuItem inherits Command, so it has type, label, icon etc. We could merge those two interfaces. The spec has no Command interface. Do you mean HTMLCommandElement, or the command* attributes on HTMLElement? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] seamless iframes and event propagation
On Mon, 9 Jul 2012, Ojan Vafai wrote: I'd like to see us add event propagation into the parent document for seamless iframes, e.g. key and mouse events inside a seamless iframe should be refired on the iframe element. I've done the HTML side of this (a paragraph), but the heavy lifting for this will be in DOM. Anne and I spoke about this earlier in #whatwg if you want to see the discussions. Some pointers to the logs can be found in the relevant DOM bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18780 I'll look into adding a flag to turn this on and off from inside the frame when I do the cross-origin seamless flags. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: allow itemid to record multiple identifiers for an item
On Tue, 4 Dec 2012, Ed Summers wrote: Over on a schema.org related list [1] there has been a discussion about making identifiers for bibliographic items (books, articles, etc) available in microdata using itemid. The use case is well described in the dev edition, with this example [2]: dl itemscope itemtype=http://vocab.example.net/book; itemid=urn:isbn:0-330-34032-8 dtTitle dd itemprop=titleThe Reality Dysfunction dtAuthor dd itemprop=authorPeter F. Hamilton dtPublication date ddtime itemprop=pubdate datetime=1996-01-2626 January 1996/time /dl Our use case is when a publisher wants to record multiple identifiers for an item. For example The Reality Dysfunction also has an OCLC number 225870439, which can be expressed as a URI, info:oclcnum/225870439. When a property isn't the sole unique identifier for an item, just use a property instead of itemid=, as in: div itemscope itemtype=http://vocab.example.net/book; meta itemprop=id content=isbn 0-330-34032-8 meta itemprop=id content=oclcnum 225870439 dl dtTitle dd itemprop=titleThe Reality Dysfunction dtAuthor dd itemprop=authorPeter F. Hamilton dtPublication date ddtime itemprop=pubdate datetime=1996-01-2626 January 1996/time /dl /div ...or, if continuing to use URLs makes more sense: div itemscope itemtype=http://vocab.example.net/book; link itemprop=id href=urn:isbn:0-330-34032-8 link itemprop=id href=info:oclcnum/225870439 dl dtTitle dd itemprop=titleThe Reality Dysfunction dtAuthor dd itemprop=authorPeter F. Hamilton dtPublication date ddtime itemprop=pubdate datetime=1996-01-2626 January 1996/time /dl /div One alternative to using itemid would be to define an oclcnum itemprop to the relevant schema.org types. This solution is a bit unwieldy because there are so many identifier types in the bibliographic world. I imagine the same is similar in other domains. That's another possibility, yes. If having a large numbmer of properties is not practical for some reason, then having one property use a common syntax that can express all the identifier types (e.g. URLs, or the type number syntax in the first example above) can work too. Another solution would be to come up with some generic identifier mechanism, but I feel like this would then duplicate what itemid is already doing. That's fine. itemid= is intended just for the very specific case of there being a specific unique identifier that is globally used as the key by which a particular vocabulary's items are identified; if there's no such key, or there are many keys and none are more important than the others, then it's better to just use a property. Honestly, itemid= isn't really intended to be a particularly widely used feature. This is reflected by the way the spec only has one example that uses itemid=, and that example's purpose is to demonstrate itemid=. It's really just a shorthand for a property (though not one whose name can be specified in itemprop=), and if it doesn't quite fit, it's fine to ignore it and use something else. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] allowfullscreen vs sandbox=allow-fullscreen
On Tue, 31 Jul 2012, Adam Barth wrote: It's not clear to me from the spec how the allowfullscreen attribute works. It appears to be mentioned only in the security and privacy considerations section. It wasn't specced. Finally got around to fixing that. For example, suppose I have three frames: Main frame: a.html - iframe src=b.html - iframe src=c.html allowfullscreen Can c.html go full screen? Where is that specified? HTML (if I got it right) says no. On Tue, 31 Jul 2012, Adam Barth wrote: Even if we don't use the iframe@sandbox syntax, it might be worth re-using the spec machinery because it's good at solving problems like the above. Please do take a look at the patch and see if it does what you think it should. Some of the machinery is indeed re-used: http://html5.org/tools/web-apps-tracker?from=7563to=7564 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Specification unclear about how HTMLElement.prototype.onscroll's getter/setter should behave for body elements
On Mon, 3 Dec 2012, Boris Zbarsky wrote:
Consider this testcase:
var desc = Object.getOwnPropertyDescriptor(HTMLElement.prototype,
onscroll);
desc.set.call(document.body, function() { alert(this); });
Is the listener added on the body, or the window?
The relevant parts of the spec are:
1) onscroll is present on both HTMLElement.prototype and
HTMLBodyElement.prototype. This testcase explicitly invokes the setter for
the former.
2) The spec text at
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#handler-onscroll
(scroll up; there is no way to link to the actual text) says:
The following are the event handlers (and their corresponding event
handler event types) that must be supported by all HTML elements
other than body and frameset, as both content attributes and IDL
attributes, and on Document objects, as IDL attributes
It's not clear to me what this means since the properties are on
HTMLElement.prototype so they can be applied to all HTML elements.
What does this text mean in terms of the testcase above?
Basically, I can see three possible behaviors here. Either the
HTMLElement.prototype.onscroll setter behaves the same way on all
elements (and hence the above adds the event handler on the body) or it
behaves specially for the body element, forwarding to the window (and
then we don't need HTMLBodyElement.prototype.onscroll), or it throws for
the body element. Which one is intended?
What do browsers do?
This should probably be defined in WebIDL. It relatess also to:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17201
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Specification unclear about how HTMLElement.prototype.onscroll's getter/setter should behave for body elements
On Mon, 3 Dec 2012, Boris Zbarsky wrote:
You have IDL like this:
interface Foo {
attribute EventHandler onscroll;
};
interface Bar : Foo {
attribute EventHandler onscroll;
};
WebIDL already defines how this behaves: there are getters/setters on
both Foo.prototype and Bar.prototype, and it's up to the spec prose to
decribe how those getters/setters actually behave. That's really what's
missing here, no? Again, there are several possible behaviors; the
question is which one we want for this particular case.
I'd really like to have WebIDL define the behaviour rather than HTML,
though.
Note that onerror has a different type on HTMLElement and HTMLBodyElement.
It relatess also to:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17201
It's a similar situation, yes. But in this case I don't see why you'd
need an IDL annotation of any sort at all. If you want the behavior to
be the same, just don't define onscroll on Bar at all and define the one
on Foo to special case the two Foo subclasses you care about here. If
you don't want it to be the same, the IDL annotation doesn't help you.
onscroll is a case where there's really no reason to use a different
setter, agreed. So I've commented that out (and it's similar friends).
That still leaves onerror though.
On Tue, 4 Dec 2012, Cameron McCormack wrote:
I agree. But if we really do need a separate namedItem (for bug 17201)
on HTMLPropertiesCollection, then there is no harm in having it too, but
I would have it not work on other HTMLCollection objects.
And vice versa.
Per our IRC discussion just now, I think I would propose that when a
method/setter/getter from a prototype of interface A is called against an
object that is of an interface B (or one of B's descendants), where B is a
subclass of A, and B defines its own method/getter/setter with the same
name, then it should throw.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas in Workers
On Fri, 30 Nov 2012, Gregg Tavares (社�~T�) wrote: on ImageBitmap should zero size canvases just work (and create a 0 sized ImageBitmap)? My personal preference is for APIs that just work with zero sizes so I don't have to write lots of special cases for handling zero. For example [1,2,3].slice(0,0) returns []. It doesn't throw. abc.substring(0,0) returns it doesn't throw. fillRect(x, y, 0, 0) doesn't throw. etc... It just makes life a lot easier The main reason 0-sized canvases have always thrown in drawImage() is that I couldn't work out what you would paint, nor why you'd have a zero-sized canvas, and throwing seemed like it'd be the best way to help the author figure out where the problem was, rather than just ignoring the call and having the author scratch their head about why nothing was happening. If there's cases where you would legitimately end up with zero-sized canvases that you'd try to draw from, though, I'm happy to change it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Firing all the the end messages on abort
On Wed, 29 Aug 2012, Boris Zbarsky wrote: On 8/29/12 6:11 PM, Ian Hickson wrote: Documents that are aborted do not need to work, they were aborted precisely because they don't need to work and are no longer needed. Or because once again some ad was taking forever to load and the web page developer is doing all their stuff from onload, so the user just hit stop to finally get the damn ui to show up. On Thu, 30 Aug 2012, Simon Pieters wrote: Indeed. It would be pretty bad user experience if we didn't fire load when the user clicks stop. That's for the stop key, though, right? Not for aborts that occur e.g. due to navigation, document.open(), or window.stop(). The spec doesn't say what browser UI should do, so if this is just about the stop key, I don't think this needs a spec change. The browser can do whatever it wants when you hit the stop key, e.g. just closing all network sockets, or stopping JS, or stopping animations, or whatever. As far as I can tell, firing 'load' events when a document gets aborted due to new navigation, or document.open(), or window.stop(), is not Web-compatible. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Make DOMStringMap constructable, and el.dataset writeable?
On Fri, 30 Nov 2012, Tab Atkins Jr. wrote: She's making a game, where the game initialization script expects certain types of elements, and for the initial state data of the elements to be present in data attributes on them. She'd like to be able to pause the game, shifting all the state data into localStorage, then later resume by pulling it back onto elements before starting the game script. Presumably you wouldn't necessarily want to grab _all_ the data-* attributes, since some might be from other libraries, or temporary transitional values used for animations or tracking things like mouse position. It would be somewhat cleaner if she could simply construct a DOMStringMap and assign it I don't really understand what you would do with the DOMStringMap and localStorage. Can you elaborate? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Make DOMStringMap constructable, and el.dataset writeable?
On Fri, 30 Nov 2012, Tab Atkins Jr. wrote: On Fri, Nov 30, 2012 at 4:01 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 30 Nov 2012, Tab Atkins Jr. wrote: She's making a game, where the game initialization script expects certain types of elements, and for the initial state data of the elements to be present in data attributes on them. She'd like to be able to pause the game, shifting all the state data into localStorage, then later resume by pulling it back onto elements before starting the game script. Presumably you wouldn't necessarily want to grab _all_ the data-* attributes, since some might be from other libraries, or temporary transitional values used for animations or tracking things like mouse position. Nah, that's fine. Might be non-optimal in some cases, but then you can just pick them out individually. Well that's kind of my point. You can pick them out individually... how common is it going to be that you want all of them? It would be somewhat cleaner if she could simply construct a DOMStringMap and assign it I don't really understand what you would do with the DOMStringMap and localStorage. Can you elaborate? Sorry, when putting it in localStorage, you have to serialize it to JSON. Then you want to revive it as a DOMStringMap initialized by an object. If you're going to do all that work, why not just do it with the element? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Making cross-origin iframe seamless= (partly) usable
frame to define it's relationship to the parent frame. Yeah. It seems to me like the best solution is to have a new HTTP header, with the four following values being allowed: Seamless-Options: allow-shrink-wrap Seamless-Options: allow-styling Seamless-Options: allow-shrink-wrap allow-styling Seamless-Options: allow-styling allow-shrink-wrap (Split on spaces, ignore unknown tokens.) Then for the per-origin control, we would extend CSP to have a flag for limiting who is allowed to embed you (subsuming X-Frame-Options, essentially). For the case of things that can be embedded by anyone but only seamlessly by paying clients, I would recommend putting the origin in the URL, and then limiting the embedding to that URL using CSP. Is this a viable direction? (There was also some discussion about how it should maybe be possible to do cross-origin DOM access, but that isn't really an option, as was discussed in the thread, so I haven't explored it further.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
On Thu, 29 Nov 2012, Gordon P. Hemsley wrote: The apparent contradiction occurs when, e.g., an Opus file is tagged as application/octet-stream. If I understand correctly, a UA would return when canPlayType() is called against such a file—but then the file would actually play because it is later sniffed as application/ogg. canPlayType() isn't called against files, it's called against MIME type strings. The type application/octet-stream isn't a video or audio file type, so we know that the browsers can't play files actually of that type, any more than the browsers can't play videos of type text/css. But when a file is labeled with that type, we know it's probably mislabeled, so we try to do something more useful. On another note, the spec's current behavior with media elements and sniffing is actually very much up in the air, since the last time I worked on this I could not get browser vendors to agree on what to implement. Search for the note starting This specification does not currently say whether or how to check the MIME types of the media resources. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache Error events
On Thu, 29 Nov 2012, David Barrett-Kahn wrote: So are there no objections to this, should I draft a change to the spec? The process, insofar as we have one, is what is described here: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F At some point, I get around to examining all the e-mails on a topic, and I try to determine what level of interest there is from implementors, and then I respond. Right now my lag is about four months, though it tends to be longer for requests for new features and shorter for major bug fixes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding crossorigin= to more elements
On Wed, 28 Nov 2012, Boris Zbarsky wrote: On 11/28/12 7:42 PM, Ian Hickson wrote: Done, at least on the HTML side. For now it just makes .sheet return null for cross-origin resources. Pretty sure that's not web-compatible... Yeah, I don't expect it is. This stuff is going to change as part of the bug below though so I'm not too worried for now. If that's not quite right, please update this bug with the details: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703 Done. Thanks. An open issue: what to do about @import? I haven't done anything magic here yet. Inheriting the CORS mode from the importing sheet is a bit weird, and I wasn't quite sure I wanted to make CSS syntax changes at this time. Inheriting the mode isn't so bad, all it really does is decide whether or not to send an Origin header. Not quite. It also affects what happens when the server doesn't respond with an appropriate Allow-Origin. A CORS-enabled load from a server that knows nothing about CORS will throw away the sheet, while a no-CORS load will happily apply the sheet to the page (but not give access to its data). So inheriting the mode can cause drastic changes in behavior compared to not inheriting it... Well, yeah, but the sheet knows which mode it's in, so I don't think that part of it is a big deal. If the CORS mode is inherited from the importing sheet, then I think the origin for the fetch should be the page, not the importing sheet, since the page is what would get access to the stylesheet data. Right, the origin of the importing sheet in this situation is the origin of the page that imported it, not the origin of its URL. That's what CORS does, it changes the effective origin of a resource from being the origin its URL would suggest it had, to being the origin of its caller. That's not quite correct. It changes the _object_ origin to that of the caller. It doesn't change the _subject_ origin. True (assuming we define those terms somewhere). The real issue here is that CSS is different than other things we've applied CORS to before, in that it is, to some level, alive. Before we've applied it to bitmaps (that can't do anything), scripts (that aren't in any way limited in the first place), and media (that can't do anything). This is the first time, I think, that we've used CORS with something that can do something with its privileges. Anyway, this is somewhat moot to me because it'll all have to be defined by whatever spec it is that currently says that a CSS sheet on http: can't import an image on file:, etc. On Wed, 28 Nov 2012, Boris Zbarsky wrote: Oh, I see. You've added this taint thing, which you're using for the CSS bit. That only applies when there's no crossorigin= attribute, unless I made a mistake in the speccing. I don't believe Gecko has any such concept. Well presumably you don't block all cross-origin loads of CSS when there's no crossorigin= attribute. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A link rel=stylesheet scoped usecase
On Fri, 8 Jun 2012, Kang-Hao (Kenny) Lu wrote: (12/06/08 7:28), Ian Hickson wrote: It still seems like a bit of an edge case, so I think it's ok for us to continue to rely on @import for this for now. But we should keep an eye out for how often people use this technique; if it is indeed something that comes up a lot, then introducing scoped= on link rel=stylesheet would make sense. (12/03/03 2:03), Kang-Hao (Kenny) Lu wrote: A reader of html5doctor had the same problem too[1] and I can certainly image other people being confused by this. [1] http://html5doctor.com/the-scoped-attribute/#link which I mentioned, Googling the string html5 scoped @import gives me the following sites which mention this technique, even if there's only one browser supporting the 'scoped' attribute at the moment: [2][3][4] [2] http://www.codingforums.com/showthread.php?t=242411#postcount1154993 [3] http://www.webdirections.org/blog/on-the-abominable-proposed-html5-scoped-attribute-for-style-elements/#comment-222761 [4] http://www.peterrknight.com/loading-javascript-and-css-mid-page-html5-wordpress-passing-validation-part-1/ Yeah, that's fair enough. Righ now I can't find any browsers that implement style scoped. Unless link scoped is preferred by vendors than style scoped, I'd rather get one implemented and proven to work before we add more, so I still haven't added link scoped. To make sure I don't forget about this, though, I've filed it as a bug and will mark it LATER. https://www.w3.org/Bugs/Public/show_bug.cgi?id=20166 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Exposing framerate / statistics of video playback and related feedback
On Tue, 1 May 2012, Charles Pritchard wrote: The list looked at having a (canvas) ctx.stream = mediaElement; option to better copy frames from a media stream into Canvas. I don't think that the assignment operator will work, but it does seem like we could optimize our drawImage calls to only happen when needed. At present, we simply would run requestAnimationFrame. But, if a video stream is operating on a slower frame rate than rAF, then the drawImage + rAF method will be wasteful. I've suggested an onframeready event; it seems as though that event could also carry the number of dropped frames. I haven't added this, because copying a video one frame at a time doesn't seem like an efficient way to do anything. Some sort of mechanism like what I had proposed for WebRTC (not sure if it's still in there) seems like a more solid solution, letting the browser do all the heavy lifting (potentially off the main thread). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding crossorigin= to more elements
On Thu, 29 Nov 2012, Boris Zbarsky wrote: Anyway, this is somewhat moot to me because it'll all have to be defined by whatever spec it is that currently says that a CSS sheet on http: can't import an image on file:, etc. Heh. Does it affect things like CSP in any way? No idea. Adam? That only applies when there's no crossorigin= attribute, unless I made a mistake in the speccing. Oh, ok. Sorry. Reading diffs of HTML is a pain. :( Yeah, couldn't agree more. If you have any idea how I can improve this, by the way, let me know. I tried running HTML diff tools for a while, but couldn't find one that actually could handle a 5MB file, and in any case they didn't really make things any more readable than plain text diffs in practice. Sure. We don't do any sort of tainting either, though; we simply remember the origin of the CSS (where it was actually loaded from, post-redirect, not the original URI) and do a same-origin check when you try to use the CSSOM on it. Note that this check is done against the effective script origin of the script doing the CSSOM access, which may not actually match the origin of the page the CSS is loaded for, etc. Not sure whether the tainting setup you describe is equivalent to that, though I doubt it is. The behaviour called tainting in this context in the spec just means treat as a cross-origin resource as opposed to treat as a network failure. The term comes from the first time I introduced crossorigin=, which was for img, where the default behaviour of cross-origin images as opposed to same-origin images is that they taint the canvas. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Load events fired during onload handlers
block this case, so that makes sense. I've put the above suggestion in the bug, if nobody objects to it then I'll spec that. On Thu, 2 Aug 2012, Henri Sivonen wrote: For what it's worth, I think the weirdness described in this thread is a good reason not to try to make DOMContentLoaded consistent with the load event for the sake of consistency. For one thing, the code that manages the weirdness of the load event lives in a different place compared to the code that fires DOMContentLoaded. Per spec they're about as consistent with each other as they can be, currently. (That's not to say that they're correctly specced; indeed there's an outstanding bug about making the abort steps work like the the end steps.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Adding crossorigin= to more elements
On Thu, 1 Mar 2012, Robert Kieffer wrote: For reasons documented in https://bugzilla.mozilla.org/show_bug.cgi?id=696301, I�d like to propose that support for the �crossorigin� attribute be added to SCRIPT tags. tl;dr - When applied to window.onerror information, the same-origin policy makes it near-impossible to host script resources on a CDN, while simultaneously using window.onerror to gather information about JS errors. Done. On Tue, 28 Aug 2012, Boris Zbarsky wrote: I just added support for link rel=stylesheet crossorigin in Gecko.[1] Such links are subject to CORS checks if the load is cross-site, and the sheet load will fail if the CORS check fails. If the CORS check succeeds, script in the page will be able to script the cross-site stylesheet. This allows stylesheets served from a CDN to be scripted by the page if desired, so I would like to propose that we add this feature to the spec. Done, at least on the HTML side. For now it just makes .sheet return null for cross-origin resources. If that's not quite right, please update this bug with the details: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703 ...and I'll try to fix it when I update that part of the spec (the CSSOM/HTML coordination). An open issue: what to do about @import? I haven't done anything magic here yet. Inheriting the CORS mode from the importing sheet is a bit weird, and I wasn't quite sure I wanted to make CSS syntax changes at this time. Inheriting the mode isn't so bad, all it really does is decide whether or not to send an Origin header. On Tue, 28 Aug 2012, Boris Zbarsky wrote: If the CORS mode is inherited from the importing sheet, then I think the origin for the fetch should be the page, not the importing sheet, since the page is what would get access to the stylesheet data. Right, the origin of the importing sheet in this situation is the origin of the page that imported it, not the origin of its URL. That's what CORS does, it changes the effective origin of a resource from being the origin its URL would suggest it had, to being the origin of its caller. Maybe this is OK, but it's non-obvious; usually for security purposes the importing sheet is what affects things like can-load checks, Referer headers, etc. Presumably a CORS-same-origin sheet would use the security characteristics of the page, since the page can make the style sheet dance as if it was its puppet. Anyway, that part of it belongs in CSS/CSSOM. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Prerendering and APIs
On Mon, 9 Apr 2012, Boris Zbarsky wrote: On 4/9/12 2:16 PM, Gavin Peters (蓋文彼德斯) wrote: However, this is strikingly similar to two other cases: when alink rel=stylesheet ... element is removed from the document, in WebKit, we remove the stylesheet from the document, although this isn't explicitly specified in 4.12.5.11, http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-stylesheet. In this situation, Gecko removes the stylesheet from the document, but does not stop its load and keeps it in the per-document object cache. Fwiw. Spec somewhat updated (.sheet now changes to null if you take the link or style out of the document), though I'll revisit this as part of: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703 ...to make it more precise. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)
On Tue, 8 May 2012, James Greene wrote:
The problem [with window.onerror is] that this mechanism does not allow
us to inspect the pertinent Error object at all: it only provides us
with three arguments at invocation time: message (string), fileName
(string), and lineNumber (number). These are rarely useful in practice.
Could you elaborate on what the exception object (Error or DOMException or
whatever) provides that the onerror callback's arguments don't, that you
would find useful for debugging? Is it just the stack trace?
On Wed, 9 May 2012, Simon Pieters wrote:
## My proposal(s) to fix it
As such, I propose the following two options as fixes:
1. Add a function like `getLastError` to the global `window` object that
would fetch the actual `Error` object associated with the most recent
unhandled error. I would foresee common usage looking something like the
following:
```
var oldOnError = window.onerror;
window.onerror = function myErrorHandler(errorMsg, url, lineNumber) {
if (oldOnError) {
return oldOnError(errorMsg, url, lineNumber);
}
var e = window.getLastError();
alert(Globally unhandled error! But we now can discover its origin.
Details: + e);
return false;
}
```
2. Alternatively (though less preferably), we could also update the
invocation arguments of `window.onerror` callbacks to include a new fourth
argument that would be the relevant `Error` object itself:
```
var oldOnError = window.onerror;
window.onerror = function myErrorHandler(errorMsg, url, lineNumber, e) {
if (oldOnError) {
return oldOnError(errorMsg, url, lineNumber, e);
}
alert(Globally unhandled error! But we now can discover its origin.
Details: + e);
return false;
}
```
While this essentially makes the first three arguments useless, I have
posed it this way for the sake of backward compatibility.
I'd prefer this second option (except making it the fifth argument),
because the exception object can become garbage earlier and because for
cross-origin script errors, the arguments to window.onerror are masked
for security reasons, and we would need to mask the exception object as
well, so it seems better to use the same mechanism for that.
I don't really understand the practical difference between these two
options, assuming getLastError() only returns a value while the onerror
handler is being invoked. (If it returns a value after it's invoked, you
get the problem zcorpan describes above, of the value not being garbage
collectable until much later.)
Also for compile script errors, there is no exception object.
That's a good point also.
On Fri, 11 May 2012, James Greene wrote:
I personally am interested in adding the stack trace, yes, but ideally I
would just have access to the full Error object so I can always have
an up-to-date model if the Error object continues to change (as it
probably will). For example, some devs may be interested in the Error
object's name property, which is already a part of the object today
but is not provided to window.onerror callbacks. And again, if
additional properties are added in the future, it's just more and more
properties that may need to get incrementally added to the
window.onerror invocation arguments list.
Having the exception object, if any, in the onerror callback, seems
reasonable, and would indeed limit how many more arguments we may have to
add over the years. It seems that providing it as an argument would be
better than as a global, though.
For example, I proposed the addition of an innerError property (or
some would call it cause) for chaining errors and masking internal
errors that consumers shouldn't see, instead providing a customer-facing
message.
I'm not familiar with that proposal.
On Fri, 11 May 2012, James Greene wrote:
Alright... so what's next? I'm assuming this needs further discussion
with other WHATWG members chiming in. If I can help, please let me
know. I'd like to see this request through.
Discussion isn't really what's needed, so much as commitments (or at
least, positive interest) from browser vendors. See this FAQ entry:
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
In general, providing the exception object as a fifth argument to onerror
seems reasonable to me. Any implementors interested in adding this?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A plea to Hixie to adopt main
On Wed, 28 Nov 2012, Silvia Pfeiffer wrote: But we already have this. The main content is whatever content isn't marked up as not being main content (anything not marked up with header, aside, nav, etc). I tried to validate that claim. It's not really possible with today's Web pages, since they haven't moved to making use of these elements, but I made some educated guesses as to where they would be used sensibly on a normal Web page. I have applied this to Google search results, Facebook user pages, YouTube video pages, and Wikipedia articles as examples of some of the most used content on the Web. You can see my results at http://blog.gingertech.net/2012/11/28/the-use-cases-for-a-main-element-in-html/. I think you're massively over-complicating what needs to be authored here. For example, with a Google search, just mark up everything up to the id=main in a header, mark up the id=top_nav as a nav, and mark up the id=foot in a footer, and what's left is the main content. (Note that this does _not_ map to what the authors would have marked up using main, as determined by looking at what they marked up with id=main -- that contains the navigation.) I don't have a Facebook account so haven't checked that one. I don't know what you'd mark up on youtube.com because I don't know what is the main content there. But marking up all the children of id=body-container as header except the id=page-container child, and marking the id=guide-container and first class=branded-page-v2- secondary-col as aside, would make the stream in the middle be the first main content, which is probably what the page author intended. This again doesn't match what the author would likely use for main -- id=content -- which contains the second of those asides currently. Wikipedia already has role=main on the appropriate element, and all the stuff that isn't main (except the appeal) comes after that, so they're fine either way, even without ARIA. Their divs map pretty directly to the elements in HTML so that the algorithm I describe above would surface the main content fine. I believe that none of the heuristic approaches work 100% of the time. Sure. Nor would main. However, on pages written correctly, main would work no better than what HTML already has. Moreover, the difference is that this is main's only purpose, and so the fact that it doesn't solve it all the time means it can't be relied upon, whereas the other elements have other purposes, so that they don't satisfy this 100% of the time doesn't make them pointless. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Menus and Toolbars
(If you're cc'ed, your opinion likely affects implementations of this and so your input is especially requested. See the question at the end. If you reply to this, please strip the cc list as the mailing list software will otherwise block your post for having too many cc's. Thanks.) There's a big section in the spec that tries to do three things: * context menus * toolbars * menu buttons Right now it's not implemented by anyone, though Firefox has a variant. http://whatwg.org/html/#the-menu-element This section has two big problems: 1. Styling of toolbars and menu buttons is just not defined. Toolbars could be a purely stylistic issue, to be solved either excluively by CSS, or CSS plus a component/widget binding model (whatever solution we end up with for that). Menu buttons are a real widget, though, so we can't just leave them to CSS styling of divs, there needs to be some real styling going on. Right now, because of the algorithm mentioned in #2 below, this is very complicated. I'll get back to this. (Styling for context menus is not a big deal, they just use native UI.) 2. Nobody is implementing it, in particular, the algorithm that converts HTML elements into a menu structure seems unpopular. Right now, the spec has this algorithm that defines how to map existing HTML semantics to a context menu or menu button (or toolbar, though the latter is less important if we move to a pure-CSS rendering model for toolbars, since we'd just drop the algorithm for them then). The idea here is that you don't have to use JavaScript to replicate the effects of existing semantics. For example, if you want a menu button which acts as a navigation mechanism, you just put a elements in your markup and they automatically get turned into menu items. There's also a generic command element for when you don't need an existing element to be used. Firefox essentially only implements this, though it's called menuitem in Firefox. command also supports an attribute that points at other elements to indirectly define features. To move forward on this, here are some proposals: #1: Drop menu and all related features. I don't think we should do this, but if we can't get agreement on what to implement, this is the only option left, so it's on the table. #2: A design that supports context menus and menu buttons using dedicated markup, with support for indirect defining of commands. First, we make menu type= take three values: toolbar, which just means to render the element using CSS (the default value for legacy pages, too), and context and button, which define menus. context menus would be hidden by default, button menus would render as a button, which, when clicked, shows the menu. contextmenu= can be used to point to a menu type=contextmenu. The menu element in context and button modes would only have three elements as descendants: menuitem elements, menu elements, and hr elements. (Or maybe no hrs, and we do separators by using groups of menu elements without labels.) Other children are ignored. menuitem elements would just have a label= attribute and, optionally, a command= attribute. The command= attribute would work as it does in the spec now, deferring to some existing element. When the menu item is selected, it would fire click on the menuitem, and then as a default action do whatever the action of the command= is, if specified. (We can talk about whether to bother supporting icons in the menuitem, and if so how, especially given high-res screens, but that's a minor detail.) With type=button, CSS would apply to the menu and menuitem elements, maybe with a limited set of properties applying. Long term, we look to XBL or Web components or whatever for styling. We drop command entirely. #2a: Same as #2, except we keep command as a way to introduce commands without using existing elements. #3: We forget the non-JS case; so, the same as #2, but menuitem doesn't get a command= attribute. We add radio menu items, checkbox menu items, and the like, over time, as features on menuitem. (Defined much like command has some of them defined today.) #4: We do what the spec has now. #5: We do what the spec has now, except we change the type=toolbar to just be rendered in CSS (and remove type=list, making toolbar the default). #6: Your idea here. So, implementors: Which of these would you be willing to implement? Are there constraints I've not thought of? Are there features that we need to deal with that I haven't mentioned above? Are there use cases that we should just abandon that could simplify the solution drastically? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] ruby markup problems
On Tue, 27 Nov 2012, Tab Atkins Jr. wrote: The current HTML ruby markup has a few issues where it does not properly solve the relevant use-cases. In this email I'll outline these problems, and suggest some simple fixes that maintain the overall simplicity of the ruby model. Thanks. My mail client has many great features, but handles non-ASCII embarassingly poorly. To avoid that getting in the way of discussing this particular topic, I've filed two bugs from your e-mail and will use them to track this specific issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20114 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20115 (As a general rule I encourage people to prefer e-mail for feedback; this is an exception.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A plea to Hixie to adopt main
On Wed, 28 Nov 2012, Silvia Pfeiffer wrote: On Wed, Nov 28, 2012 at 10:35 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 28 Nov 2012, Silvia Pfeiffer wrote: But we already have this. The main content is whatever content isn't marked up as not being main content (anything not marked up with header, aside, nav, etc). I tried to validate that claim. It's not really possible with today's Web pages, since they haven't moved to making use of these elements, but I made some educated guesses as to where they would be used sensibly on a normal Web page. I have applied this to Google search results, Facebook user pages, YouTube video pages, and Wikipedia articles as examples of some of the most used content on the Web. You can see my results at http://blog.gingertech.net/2012/11/28/the-use-cases-for-a-main-element-in-html/ I think you're massively over-complicating what needs to be authored here. For example, with a Google search, just mark up everything up to the id=main in a header, mark up the id=top_nav as a nav, and mark up the id=foot in a footer, and what's left is the main content. (Note that this does _not_ map to what the authors would have marked up using main, as determined by looking at what they marked up with id=main -- that contains the navigation.) Agreed. But what the authors have marked up as @id=main is not relevant for this discussion - Yes, it is, because by and large that's exactly the element that people are going to use main for. Most people aren't going to use main for accessibility reasons. That's not how most authors think. They'll use it for styling. We have to design the language with that in mind. That's why we have things like header and nav and aside _instead_ of something like main. The feedback that I get from blind users is: the main content is the video and I can't find it. Then browsers should let blind users have the ability to jump to video elements. No need for the page to be marked up at all being video. (But not that there's no video on the youtube.com home page, unless you mean the ad.) When authored correctly or corrected after feedback from blind users, it will work - Exactly. In other words, it won't work, because it's unlikely to be authored correctly, and feedback from blind users by and large has no effect on sites. There's also the assumption that what you want is just to jump to a part of the page, rather than read the page from top to bottom, just skipping the parts of the page that aren't hugely interesting, like navigation. I actually think that's the better UI here. That is, rather than: DALLAS - On a rainy night in early Summer, a tiny kitten with... ...getting: Pegasus News. (skipping navigation, press space to hear skipped sections.) Help Charlie the kitten find a new home. (skipping navigation.) DALLAS - On a rainy night in early Summer, a tiny kitten with... Even in the best-case scenario, main gets you the worse UI above, whereas using nav and aside and so forth can get you the second. http://www.pegasusnews.com/news/2012/nov/27/help-charlie-kitten-find-new-home/ All of this has already been discussed on this mailing list, so this is not new information. I would please refer you to the earlier messages on this topic. In general, unless there is substantial new information, please don't keep posting on a thread in this mailing list -- the list is high-traffic enough without us covering old ground (which is unlikely to result in a different outcome if nothing has changed). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] inner shadows
On Sat, 24 Nov 2012, Rik Cabanier wrote: How about the strokes? The example in the OP didn't have them, but you'd have to include them in the fill area. With the new Path objects, you'd just use addPathByStrokingPath(), which would be relatively simple. Unfortunately the winding rules will mess up your shape. (non-zero winding) Take for instance a stroked circle. The stroke which is added with addPathByStrokingPath will always create a hole so you end up with a donut instead of just a slightly larger circle. Right: So long as they don't overlap, that's not generally a problem. But sure, for some complex shapes you'd need some new feature or other, whether it's in shadows or path construction or elsewhere. In the case of a circle, if you wanted to draw the inner shadow over the stroke and the fill, you'd have to create the path as just a fill with the radius increased by half the line width. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] canvas and high-density displays
On Mon, 24 Sep 2012, Glenn Maynard wrote: On Mon, Sep 24, 2012 at 6:40 PM, Ian Hickson i...@hixie.ch wrote: We could add an event that fires on ImageData (or even ArrayBuffer) that fires when the data is available. If we add it to ArrayBuffer it's something that could be used in other contexts, too. Is this something that people think we should do? If so, should we add it to TypedArray generically? If it's done this way, a nonblocking function may be needed to request that the event be fired, without the blocking side-effects of actually performing a pixel read. Otherwise, implementations that don't perform the readback at all until it knows it's really needed (eg. that it can't be done with an in-GPU blit) would simply never fire the event at all. Passing in a callback probably makes more sense this way than having it request that an event be fired. That would also allow waiting for readability without knowing in advance whether the event was already fired or not, which would be important eg. if you just received the ArrayBuffer in a message. (An attribute could do this as well, but that might be more prone to developer error.) Indeed. If this is something that people want to follow up on, I recommend suggesting it to the WebGL mailing list where Typed Array lives. I don't think it makes sense for us to do a version just for canvas. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] inner shadows
On Fri, 21 Sep 2012, Tyler Larson wrote: On Sep 20, 2012, at 6:49 PM, Ian Hickson i...@hixie.ch wrote: Can't you do this using clip() easily enough? Maybe I'm missing something important here. Can you elaborate? Here is an example of what I am talking about. http://i.imgur.com/Sy4xM.png Clip would mask something but adding an inner shadow is different and pretty difficult to reproduce when you take into account complex shapes. Ah, yeah, I see what you mean. The problem is that the canvas rendering model always renders the shadow under the shape, and uses the shape's alpha to work out where to paint the shape. What we could do is offer control that would change the shadows from rendering under the shape to rendering over the shape, or, maybe even better, have a mode that only renders the shadows. Then you could achieve these effects relatively easily (by clipping to the shape so that the shadow only renders inside the shape). Is this something implementors would be interested in? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 video seeking
is that at present, range inputs are not quite sufficient semantically for marking up seek bars. Seek bars typically display not only a thumb, but also a progress bar that displays what percentage of the video is loaded. Obviously, we have progress for this, and so theoretically one could use both a range input and a progress bar together, this falls short for a few reasons: [...] There's basically two ways we can address this: 1. Extend input type=range and progress to support more complicated UIs, e.g. including data in the range control to visualise buffering, playback, etc; having a way to provide a tooltip; having a way to have more careful positioning like YouTube's seek bar on long videos; having a way to get information about the position the user is hovering over before the user clicks; etc. 2. Have something like Web Components, enabling authors to create custom widgets that support whatever they want. I expect we'll do both, on the long term. However, on the short term, I think we should delay #1 until we have much better implementations of the current widgets in all the major browsers. #2 is ongoing, but might take a long time also. So in the meantime, you're kind of stuck without a good solution. Sorry. I would recommend going to the old standby, divs and lots of CSS, script, and ARIA attributes (this is what ARIA is useful for!). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] inner shadows
On Fri, 23 Nov 2012, Ian Hickson wrote: On Fri, 21 Sep 2012, Tyler Larson wrote: On Sep 20, 2012, at 6:49 PM, Ian Hickson i...@hixie.ch wrote: Can't you do this using clip() easily enough? Maybe I'm missing something important here. Can you elaborate? Here is an example of what I am talking about. http://i.imgur.com/Sy4xM.png Clip would mask something but adding an inner shadow is different and pretty difficult to reproduce when you take into account complex shapes. Ah, yeah, I see what you mean. I was wrong, I didn't see what you mean. Turns out it's relatively easy to do today in canvas; after you've drawn your shape and filled it, just add the following code: c.save(); c.clip(); c.moveTo(0,0); c.lineTo(0,height); c.lineTo(width,height); c.lineTo(width,0); c.closePath(); c.shadowColor = 'black'; c.shadowBlur = 30; c.fill(); c.restore(); -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Enabling LCD Text and antialiasing in canvas
On Thu, 29 Mar 2012, Jeremy Apthorp wrote: On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp jere...@chromium.orgwrote: On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Jan 2012, Jeremy Apthorp wrote: I'd like to draw non-antialiased lines in a canvas. Currently it seems that the only way to do this is to directly access the pixel data. Is there a reason there's no way to turn off antialiasing? What's the use case? Pixel-art style games. Specifically: even with the new image smoothing stuff in place for drawImage, a 1:2 diagonal line will still be anti-aliased (only the antialiasing will look silly scaled up to 2x). Do you have an example of a game where lines are drawn using a line API without antialiasing, then scaled up? Most pixel art games I've seen tend to use bitmaps for that kind of thing. On Mon, 12 Nov 2012, Justin Novosad wrote: For many types of apps, DOM-based rendering is uncompetitively slow [so we should make text rendering in canvas more controllable] This seems like something we should fix, not something we should work around by having people use canvas instead. Using canvas has all kinds of terrible side-effects, like reducing the likely accessibility of the page, making searcheability much worse, etc. Also, do you have any metrics showing the magnitude of this problem on real-world sites that might consider using canvas instead? If LCD text were enable-able, authors would have to be mindful of a number of caveats in order to avoid rendering artifacts. Do we have any reason to believe the majority of authors would make the right decisions here? (The main reason we haven't provided control over things like antialiasing is that many authors tend to make terribly bad decisions.) (Before anyone gets offended, by the way: that you are reading this almost guarantees that you are above average in terms of authoring ability.) On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote: We'd have to define what happens when you use subpixel antialiasing incorrectly, because we can be pretty sure authors will use it incorrectly and expect to get interoperable behavior. That's certainly true. Mozilla supports a mozOpaque attribute which makes the canvas buffer RGBX (initialized to solid black) and enables subpixel antialiasing for most text drawing. That might be enough to address your use-cases. I haven't specified this; if other vendors intend to implement this let me know and I can spec it. I'm not sure it's worth it though. On Wed, 14 Nov 2012, Robert O'Callahan wrote: On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad ju...@chromium.org wrote: Are there precedents for exposing features with documented caveats? (excluding caveats that were discovered after the fact) Yes, and many of them have been extremely problematic, because Web authors will ignore the caveats. Right. I'd really like to avoid adding more if we can help it. On Wed, 14 Nov 2012, Justin Novosad wrote: There is a recent improvement in Chrome called deferred 2D canvas rendering (enabled by default as of Chrome 23). It is a mechanism that records 2d canvas commands during JS execution, and only executes them for real when the render buffer needs to be resolved (draw to screen, getImageData, toDataURL, etc.). If you want to check it out, the guts are in Skia: SkGPipe is a sort of FIFO for graphics commands, SkDeferredCanvas is a wrapper that manages the GPipe and automatically flushes it and applies some command culling optimizations. So to come back to the problem of with and without subpixel AA buffers: if rendering is deferred, the non-AA buffer would never get rasterized (and possibly never even allocated), unless it needs to be. Obviously there are practical limitations, for example we cannot store an unlimited stream of recorded commands, so if the canvas draws indefinitely without ever being cleared, at some point we have to rasterize the non-AA buffer just so that we can safely discard the recording data. Also, if at record time the necessary conditions for subpixel AA are not met, perhaps we just forget about it. I admit this is a complex solution for implementors, but it makes the management of subpixel-AA safety transparent to web authors. I think it'd be reasonable (for some definition of reasonable that relates to whether it's compatible with the spec, anyway) for implementors to do this today, without having to expose any control to the author. On Thu, 15 Nov 2012, Fred Andrews wrote: The canvas that scripts draw into could be over-sized with the UA down sampling this to fit the target size and taking into account the sub-pixel screen layout when doing so. On Thu, 15 Nov 2012, Justin Novosad wrote: Obviously, that would be costly (x3 pixels), but I think it is a very realistic solution and relatively low hanging fruit. The over-sizing
