[whatwg] some areas of ambiguity in the canvas section

A while back I did some work on WebKit's canvas implementation and I noticed a few things in the canvas section of Web Apps that I'd like to see specified so they don't end up different between implementations: a) NAN arguments For the graphics context functions that take floating point

Re: [whatwg] Canvas spec issues

On May 11, 2007, at 4:18 PM, Ian Hickson wrote: On Mon, 26 Mar 2007, Philip Taylor wrote: A couple of points that are unclear and are causing differences between current implementations (which is presumably a bad thing): interface HTMLCanvasElement says attribute long width;. #reflect says

Re: [whatwg] Canvas Zero/NaN/Infinity issues

On May 15, 2007, at 6:36 PM, Ian Hickson wrote: For the graphics context functions that take floating point values, I think the specification should say what the expected behavior is for: 1) NANs 2) non-floating point values 3) missing parameters b) excess arguments 1, 3, and b

Re: [whatwg] Canvas Zero/NaN/Infinity issues

On May 16, 2007, at 11:17 AM, Philip Taylor wrote: Existing implementations seem to try converting the value into a JS number, which will always give a floating-point value, and that's just NaN if the conversion is not possible (e.g. from an object, or undefined, or a string that can't be

Re: [whatwg] several messages

On May 16, 2007, at 5:31 PM, Philip Taylor wrote: On 17/05/07, Ian Hickson [EMAIL PROTECTED] wrote: I've changed the spec to say to ignore extra arguments and raise an exception for too few arguments. What happens when someone calls drawImage(image, dx, dy, dw)? That's too few arguments

Re: [whatwg] setting .src of a SCRIPT element

On May 21, 2007, at 10:26 AM, Hallvord R M Steen wrote: with IE's implementation you can have one data loader SCRIPT element and set its .src repeatedly. Is this technique easy to use correctly? What if you set the src before a previous script has finished loading? -- Darin

Re: [whatwg] .localName shouldn't change case

On Jun 29, 2007, at 9:15 AM, Simon Pieters wrote: For HTML elements in HTML documents, why is Element.localName uppercased for tag names and lowercased for attribute names? I wouldn't expect it to, and it makes it harder to write scripts that work for both HTML and XHTML. For example, if

Re: [whatwg] Offline Web Apps

On Sep 13, 2007, at 8:30 AM, Aaron Boodman wrote: They could rewrite bugzilla to use fragment identifiers instead of querystrings, but then bug shortcuts on the web would not work with the offline-enabled application. If you're designing a new application, even one that works both online

Re: [whatwg] Comments/questions on 4.6 Offline Web applications

On Oct 12, 2007, at 9:42 AM, Adam Roben wrote: Darin Adler wrote: On Oct 12, 2007, at 6:11 AM, Adam Roben wrote: It may be worth stating in this section what the behavior is when a section or opportunistic caching namespace appears multiple times. The parsing algorithm makes this clear

Re: [whatwg] Comments/questions on 4.6 Offline Web applications

On Oct 12, 2007, at 6:11 AM, Adam Roben wrote: It may be worth stating in this section what the behavior is when a section or opportunistic caching namespace appears multiple times. The parsing algorithm makes this clear, but it would be clearer still to also state the behavior in this

Re: [whatwg] several messages about a way to disable referer headers for links

While we are unable correct the spelling of referer, we certainly need not duplicate it for noreferrer. There must be some end to this self-humiliation. I think it's way better to stay consistent. Especially as the feature affects the Referer (sic) header. I too think Anne is right

[whatwg] Improving specification of accesskey?

Hi folks. I've been looking at an accesskey bug or two in Safari and I am quite frustrated about the poor standardization of the meaning of this attribute. I concur with the comments at http://www.cs.tut.fi/~jkorpela/forms/accesskey.html that quote the HTML 4 specification and then says:

Re: [whatwg] Improving specification of accesskey?

On Nov 7, 2007, at 11:25 AM, Michael(tm) Smith wrote: A few months back, Charles McCathieNevile proposed a spec for accesskey on the public-html list: http://lists.w3.org/Archives/Public/public-html/2007Jul/thread.html#msg185 That thread is maybe worth taking some time to read I've just

Re: [whatwg] Asynchronous database API feedback

On Dec 15, 2007, at 6:00 PM, Benjamin West wrote: I suspect that for most typical uses on most typical runtimes, most developers would choose to risk the performance hit of synchronous access to the complexity of binding methods to their objects. I suspect this allows faster prototyping

[whatwg] HTMLTableElement.deleteRow(-1)

The DOM Level 2 document http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-13114938 says that deleteRow(-1) deletes the last row. The current HTML 5 draft http://www.whatwg.org/specs/web-apps/current-work/#deleterow does not mention -1 for deleteRow, only for insertRow. I think HTML 5

[whatwg] a small hole in the traversal specification

There is no specification for what happens when acceptNode returns a value outside the range [0,2] in the DOM Level 2 traversal document. Is this something HTML 5 could patch up? I didn't yet test Gecko and IE to see what they do for this. -- Darin

Re: [whatwg] Colour correction (was: Canvas ImageData comments)

On Jan 20, 2008, at 9:10 AM, Henri Sivonen wrote: Most of the time, the solutions to the color space problem are worse that the problem itself. The easiest fix for this whole mess would be making Mac OS X default to 2.2 gamma (i.e. be compatible with the overall legacy instead of the Mac

Re: [whatwg] Some video questions

On Jan 29, 2008, at 5:11 PM, Charles wrote: Are Adobe/Microsoft going to be update their Flash/Silverlight browser plug-ins in order to be first-class video handlers Why would they? Those aren't video plug-ins. They're general purpose applet plug-ins. -- Darin

Re: [whatwg] Review of the 3.16 section and the HTMLInputElement interface

On May 14, 2008, at 9:38 AM, Samuel Santos wrote: On Mon, Feb 11, 2008 at 12:11 AM, Samuel Santos [EMAIL PROTECTED] wrote: What I propose is to add a new attribute to the input element like this: attribute DOMString browseText; this allows us developers to change the

Re: [whatwg] Scoping elements and nested paragraphs

On Nov 12, 2008, at 1:49 AM, Tommy Thorsen wrote: Consider the following markup: pobjectpX/p/p The html5 parsing algorithm produces the following tree: htmlhead/headbodypobjectpX/pp/p/object/p/ body/html whereas Firefox and Opera both produce:

Re: [whatwg] DOMTimeStamp binding

On Feb 11, 2009, at 9:38 AM, Kartikaya Gupta wrote: DOM 3 Core says this about DOMTimeStamp: For Java, DOMTimeStamp is bound to the long type. For ECMAScript, DOMTimeStamp is bound to the Date type because the range of the integer type is too small. However, when I do this: var e =

Re: [whatwg] DOMTimeStamp binding

On Feb 11, 2009, at 10:51 AM, Kartikaya Gupta wrote: Interesting. What version did you try on? I used Chrome 1.0.154.48 and Safari 3.1 (525.13) on Windows. The relevant version is the WebKit version rather than the Safari version. They have separate version numbers. I used

Re: [whatwg] DOMTimeStamp binding

On Feb 11, 2009, at 12:14 PM, Kartikaya Gupta wrote: I updated to Safari 3.2 on Windows (which looks it also has WebKit 525.27.1) and you're right, it is now showing number instead of object. I guess this was changed not too long ago. So then my question is: why was it changed? No, this

Re: [whatwg] DOMTimeStamp binding

On Feb 12, 2009, at 7:08 AM, Kartikaya Gupta wrote: Latest version of Chrome is still giving me a Date object. I don't know what version of WebKit it's using. Chrome uses an entirely different JavaScript binding, not the standard WebKit one, so I'm not surprised that it’s exhibiting

Re: [whatwg] Something better than DOM_QUOTA_ERROR when LocalStorage is immutable?

On Jun 4, 2009, at 12:27 AM, Anne van Kesteren wrote: Doesn't this reveal what mode the user is using to view the site? That seems kind of bad. It all depends on the intent of the feature. Some browsers have features intended to shield the identity of the person doing browsing from the

Re: [whatwg] DOMTokenList is unordered but yet requires sorting

On Jun 15, 2009, at 12:22 PM, Ian Hickson wrote: On Tue, 9 Jun 2009, Erik Arvidsson wrote: I was about to follow up on this. Requiring sorting which is O(n log n) for something that can be done in O(n) makes thing slower without any real benefit. Like João said the order should be

[whatwg] Possible typo in application cache section

6.9.4, paragraph 7 says, “applications caches never include fragment identifiers” and I think this should just be “application caches”. -- Darin

Re: [whatwg] [html5] Attaching option elements to select elements in different documents

Was your testing done with option elements created with document.createElement(option) or new Option? I ask because I seem to recall the behavior being different for at least some types of elements. -- Darin

Re: [whatwg] Serialization of boolean content attributes

On Jun 18, 2010, at 10:25 AM, Jonas Sicking wrote: On Fri, Jun 18, 2010 at 10:15 AM, Alexey Proskuryakov a...@webkit.org wrote: My reading of HTML5 is that boolean content attributes with no value are serialized as e.g. option selected=. That's not what shipping versions of Firefox or

Re: [whatwg] Serialization of boolean content attributes

On Jun 18, 2010, at 11:03 AM, Jonas Sicking wrote: It would be pretty trivial to make the serializer HTML aware and hold a list of which attribute are 'boolean' in which elements, no? It already is HTML aware for a host of other reasons anyway. One of the things I like about the current

Re: [whatwg] CSS2 system colors in legacy color values

On Aug 3, 2010, at 5:55 PM, Ian Hickson wrote: WebKit on Mac responds to changes to the color Highlight by changing the colour to the default blue the next time it resolves style (as far as I can tell). Not exactly a success story. (Highlight is the only colour over which the user seems to

Re: [whatwg] CSS2 system colors in legacy color values

On Aug 3, 2010, at 6:33 PM, Ian Hickson wrote: We're talking about body bgcolor=Highlight here, not about the colour of selected text. I see. And I can reproduce the bug you’re talking about. I’ll probably fix it, but point taken. -- Darin

Re: [whatwg] Javascript: URLs as element attributes

In WebKit, we have treated the javascript URL scheme as a special case, with explicit code in the loader, and not handled by general purpose resource protocol machinery. Maciej Stachowiak suggested this approach, back in 2002, and one of the reasons he gave me at the time is that thought WebKit

Re: [whatwg] getSelection().modify() in vertical writing modes

Lets find at least one example of this before we say “many rich text editors”. Do they use modify? If so, do they use left/right? I’m kind of surprised, since I believe WebKit invented the modify function, that it’s so widely used now! I would have expected use of execCommand instead. --

Re: [whatwg] Placeholder visibility on focus

On Jul 19, 2011, at 3:55 AM, Thomas Maas wrote: instead of checking for an empty string *and* focus the user agent should just check for an empty string. I think that for some user agents, whether the placeholder text is shown when the field is focused should depend on platform behavior.

Re: [whatwg] Default encoding to UTF-8?

On Dec 5, 2011, at 4:10 PM, Kornel Lesiński wrote: Could !DOCTYPE html be an opt-in to default UTF-8 encoding? It would be nice to minimize number of declarations a page needs to include. I like that idea. Maybe it’s not too late. -- Darin

Re: [whatwg] inconsistent canvas implementations of destination-in compositing

On Dec 22, 2011, at 10:35 AM, David Karger wrote: Firefox and chrome inconsistently handle destination-in compositing; I suspect this may be due to a missing specification in the standard. The inconsistency happens when I use the drawImage method to draw one canvas onto another while the

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

On Jan 10, 2012, at 8:43 AM, Boris Zbarsky wrote: So in WebKit this event is only good for preventing _processing_ of the data in the page (e.g. preventing the script from executing when the target is a script) but not much use for preventing loads, even if some people seem to think that

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

On Jan 10, 2012, at 10:59 AM, Boris Zbarsky wrote: On 1/10/12 1:54 PM, Darin Adler wrote: On Jan 10, 2012, at 8:43 AM, Boris Zbarsky wrote: So in WebKit this event is only good for preventing _processing_ of the data in the page (e.g. preventing the script from executing when the target

Re: [whatwg] Base URL’s effect on an empty @src element

On May 1, 2013, at 9:23 AM, Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no wrote: Given a document, where 1. the content of img @src is empty, and thus invalid, 2. but there is base url which points to an image Example: !DOCUMENT html base href=image.jpg/ img src= alt=Text.

Re: [whatwg] JavaScript dialogs blocking user experience

> On Apr 14, 2016, at 2:17 PM, Arvind Nigam wrote: > > My iPad is on iOS 9.3.1, but I was using the UC browser at the time. It’s too bad you were using the UC browser. If you had been using Safari you would not have been trapped by the scam. If you continue to prefer

Re: [whatwg] JavaScript dialogs blocking user experience

> On Apr 14, 2016, at 1:04 PM, Domenic Denicola wrote: > > I'm not sure whether this has much of a spec impact. The spec already allows > great leniency in these areas; e.g. > https://html.spec.whatwg.org/multipage/webappapis.html#dom-alert step 3 and > the "optionally" in

Re: [whatwg] JavaScript Hovers and Back Button

> On Apr 14, 2016, at 10:38 AM, Arvind Nigam wrote: > > I wish to add that this issue is a bit more annoying on mobile: both on > iPad and iPhone. > > Once the webpage loads, it goes into a JS invoked confirm/ok modal that > would not relent -- not without seeking credit

Re: [whatwg] JavaScript dialogs blocking user experience

> On Apr 15, 2016, at 9:35 AM, Nils Dagsson Moskopp > wrote: > > Clearly distinguishing between browser chrome and the current document > interface-wise can be helpful here. While it is incredibly easy to fool > people in general, browsers that automagically hide

Re: [whatwg] JavaScript dialogs blocking user experience

> On Apr 15, 2016, at 1:58 PM, Arvind Nigam wrote: > > While I understand your inclination towards Apple Safari, it is out of > question that people won't use other browsers like the Chrome or Firefox or > even the UC browser to surf the web. The problem you

Re: [whatwg] JavaScript dialogs blocking user experience

> On Apr 15, 2016, at 1:58 PM, Arvind Nigam wrote: > > On mobile the browser goes totally unresponsive and the infinite-loop of > modal confirmations is literally inescapable. I’ll drop this thread after this, but what I wanted to say is this: This extremely bad