Re: [whatwg] Javascript: URLs as element attributes
On Mon, 29 Nov 2010 16:36:32 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 11/25/10 9:10 AM, Philip Jägenstedt wrote: Based on this, unless there are corner-cases I've missed, it seems unlikely that there's a large body of web content that depends on inline javascript: URLs executing. My current plan is to try completely blocking javascript: URLs in the contexts mentioned above. This seems to be the simplest to implement and the fastest way to reach interoperability. The alternative is to start executing javascript: URLs in more contexts, which, even if sandboxed, doesn't seem particularly useful. Does Opera sandbox object data=javascript:? Note that Firefox does not. No, as far as I know, Opera hasn't ever sandboxed any inline javascript: URL execution. That's one reason why it's easier to just not run them at all. Also, note that embed src=javascript: and applet something=javascript: (can't recall the attr name right now) also execute the script in Firefox. Do they in Opera? Neither of these execute in Opera, both were explicitly blocked before I started looking into the issue. Note that I can't get applet something=javascript: to execute in Firefox either, perhaps it needs a special value for something or the Java plugin must be installed? I'll keep you posted if there are any compatibility issues that come up with this. Assuming (boldly) there is not, would there be support from other browsers to move in this direction and change the spec to match? (It seems that IE and WebKit are already basically already doing what I'm advocating.) The reason Firefox runs javascript: in object is https://bugzilla.mozilla.org/show_bug.cgi?id=300263. I could probably be convinced to either run it in a sandbox or not run altogether, though I would strongly prefer the sandbox approach Thanks for that pointer. For those who don't want to dig, it was about generating a SVG document for object data=. The demo https://bug300263.bugzilla.mozilla.org/attachment.cgi?id=188843 will break if you start sandboxing the execution as per spec, as it refers to eg_svg from the outer environment. It also doesn't currently work in Opera, it seems like we just execute object data=javascript:, but don't use the return value as the document. Since it also won't work in IE or WebKit, it seems unlikely that there's much content depending on this. It seems to me that after sandboxing, javascript: URLs will be quite useless. You can only use them where the content is text, and the script has to be completely self-confined. Using data: URLs will allow you to generate the data in the outer environment, and it's possible to generate binary data. For reference here's the same demo done with a data: URL instead: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/721 Unlike the javascript: version, this actually works in Opera, Firefox and presumably all browsers that support SVG in object and data: URLs. So far, it seems that the fastest way to reach compat between browsers is to simply not run inline javascript: URLs. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Javascript: URLs as element attributes
On Tue, Nov 30, 2010 at 11:35 AM, Philip Jägenstedt phil...@opera.com wrote: Also, note that embed src=javascript: and applet something=javascript: (can't recall the attr name right now) also execute the script in Firefox. Do they in Opera? Neither of these execute in Opera, both were explicitly blocked before I started looking into the issue. Note that I can't get applet something=javascript: to execute in Firefox either, perhaps it needs a special value for something or the Java plugin must be installed? based on: applet codebase=http://java.sun.com/applets/NervousText/1.1; code=NervousText.class width=400 height=75 my guess is: #define something codebase
Re: [whatwg] Tag Proposal: spelling
Am 29.11.2010 um 21:58 schrieb Charles Pritchard: Currently, there's no way for an author to markup spelling errors in text. A [spelling] tag would address that deficiency. This could be used for a number of reasons, from [sic]-style annotations, to conveying to the user that an area is misspelled using the same visual cues as contenteditable. At this point, it'd simply be a semantic element. If there's any traction, we could certainly talk about additional attributes or another name, such as sic: [sic]misspeld[/sic] Does the list need further use cases for its consideration? -Charles I support this idea and I'd certainly use it. For example, I'm currently copying an old rhyme book to hypertext and would love to mark historically correct (but now incorrect) spelling, spelling intentionally done wrong for better rhyming (yes, people did this in the past) and unintentional errors from the book semantically. I think it is important to note where those errors are done intentional (by me, the publisher of the web page) in contrast to errors accidentally added by me that differ from the copied book. I'd prefer the name sic to spelling, because if you have spelling, you'd also want elements to mark intentionally incorrect grammar, wrong numbers or whole misplaced words. Sic serves all these purposes fine. If it is necessary to differentiate between e.g. intentionally wrong grammar and intentionally wrong spelling, attributes might be a solution. Regards Martin
Re: [whatwg] Javascript: URLs as element attributes
http://download.oracle.com/javase/1.4.2/docs/guide/misc/applet.html actually, potentially each of these are probably potential candidates for something: CODEBASE ARCHIVE OBJECT
Re: [whatwg] Javascript: URLs as element attributes
On Tue, 30 Nov 2010 10:48:45 +0100, timeless timel...@gmail.com wrote: http://download.oracle.com/javase/1.4.2/docs/guide/misc/applet.html actually, potentially each of these are probably potential candidates for something: CODEBASE ARCHIVE OBJECT None of those worked for me, even with the plugin (icedtea6-plugin) installed. -- Philip Jägenstedt Core Developer Opera Software
[whatwg] Proposal: Characters data (coordinate and sizes)
Hello everyone, how about API that give ability to get information about character coordinates (and sizes) on the page. For now to get this info, we need wrap every symbol in it's own tag and calculate it position, maybe I'm wrong, but another approach I don't know.
Re: [whatwg] Proposal: Characters data (coordinate and sizes)
On Tue, 30 Nov 2010 13:33:07 +0100, Anton Byrna it.rele...@gmail.com wrote: Hello everyone, how about API that give ability to get information about character coordinates (and sizes) on the page. For now to get this info, we need wrap every symbol in it's own tag and calculate it position, maybe I'm wrong, but another approach I don't know. http://dev.w3.org/csswg/cssom-view/#extensions-to-the-range-interface -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Tag Proposal: spelling
Am 30.11.2010 um 10:46 schrieb Martin Janecke: Am 29.11.2010 um 21:58 schrieb Charles Pritchard: Currently, there's no way for an author to markup spelling errors in text. A [spelling] tag would address that deficiency. This could be used for a number of reasons, from [sic]-style annotations, to conveying to the user that an area is misspelled using the same visual cues as contenteditable. At this point, it'd simply be a semantic element. If there's any traction, we could certainly talk about additional attributes or another name, such as sic: [sic]misspeld[/sic] Does the list need further use cases for its consideration? -Charles I support this idea and I'd certainly use it. For example, I'm currently copying an old rhyme book to hypertext and would love to mark historically correct (but now incorrect) spelling, spelling intentionally done wrong for better rhyming (yes, people did this in the past) and unintentional errors from the book semantically. I think it is important to note where those errors are done intentional (by me, the publisher of the web page) in contrast to errors accidentally added by me that differ from the copied book. I'd prefer the name sic to spelling, because if you have spelling, you'd also want elements to mark intentionally incorrect grammar, wrong numbers or whole misplaced words. Sic serves all these purposes fine. If it is necessary to differentiate between e.g. intentionally wrong grammar and intentionally wrong spelling, attributes might be a solution. Regards Martin Above I only considered intentionally misspelled words to be wrapped into a sic element. For other uses such as an application highlighting a misspelled word to the user as a hint where she/he might want to correct something, the right choice would be the mark element, I think: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-mark-element Regards Martin
Re: [whatwg] Javascript: URLs as element attributes
On Tue, 30 Nov 2010 13:10:28 +0100, Philip Jägenstedt phil...@opera.com wrote: On Tue, 30 Nov 2010 10:48:45 +0100, timeless timel...@gmail.com wrote: http://download.oracle.com/javase/1.4.2/docs/guide/misc/applet.html actually, potentially each of these are probably potential candidates for something: CODEBASE ARCHIVE OBJECT None of those worked for me, even with the plugin (icedtea6-plugin) installed. How about code= (or param name=code value=javascript:)? -- Simon Pieters Opera Software
Re: [whatwg] Javascript: URLs as element attributes
On Tue, Nov 30, 2010 at 3:21 PM, Simon Pieters sim...@opera.com wrote: How about code= (or param name=code value=javascript:)? i'm assuming not, the spec claims it's not allowed to take an absolute url.
Re: [whatwg] Javascript: URLs as element attributes
On Tue, 30 Nov 2010 14:21:21 +0100, Simon Pieters sim...@opera.com wrote: On Tue, 30 Nov 2010 13:10:28 +0100, Philip Jägenstedt phil...@opera.com wrote: On Tue, 30 Nov 2010 10:48:45 +0100, timeless timel...@gmail.com wrote: http://download.oracle.com/javase/1.4.2/docs/guide/misc/applet.html actually, potentially each of these are probably potential candidates for something: CODEBASE ARCHIVE OBJECT None of those worked for me, even with the plugin (icedtea6-plugin) installed. How about code= (or param name=code value=javascript:)? Nope, I've had no luck. In any case, since Opera (and presumably IE/WebKit, although I haven't checked) doesn't run these, it doesn't seem like a compat issue to worry about. -- Philip Jägenstedt Core Developer Opera Software
[whatwg] Embedding WebSocket Servers in Web Pages
Hello, I work for the computer science department at the University of Helsinki, Finland. We've been trying to define an API that would allow web site developers to run simple servers in their web pages. The motivation behind the research is establishing some ground for browser-to-browser networking, enabling web sites to co-operate with end-user systems in new ways. Today, we are publishing our API draft and working prototype at http://browsersocket.org/ We are hoping our work will be useful for people designing related web standards. We look forward to discussing related topics on the mailing lists. --Toni
Re: [whatwg] Javascript: URLs as element attributes
On 11/30/10 4:35 AM, Philip Jägenstedt wrote: No, as far as I know, Opera hasn't ever sandboxed any inline javascript: URL execution. So img src=javascript: runs the JS in the page's context in Opera? Also, note that embed src=javascript: and applet something=javascript: (can't recall the attr name right now) also execute the script in Firefox. Do they in Opera? Neither of these execute in Opera, both were explicitly blocked before I started looking into the issue. Note that I can't get applet something=javascript: to execute in Firefox either, perhaps it needs a special value for something Right; see the can't recall bit above. code=javascript: maybe? or the Java plugin must be installed? This might be needed too, yes. It seems to me that after sandboxing, javascript: URLs will be quite useless. You can only use them where the content is text That's not the case, actually. At least in Gecko, the return value string is examined to see whether all the charcode values are 255. If they are, then the string is converted to a byte array by just dropping the high byte of every char. So you can pretty easily generate image data this way. If any of the bytes are 255, then the string is encoded as UTF-8 instead. and the script has to be completely self-confined Indeed. Using data: URLs will allow you to generate the data in the outer environment, and it's possible to generate binary data. Right. Now that data: support is universal, there may be a lot less need for javascript: returning data, except for compat reasons. So far, it seems that the fastest way to reach compat between browsers is to simply not run inline javascript: URLs. Except for frames/iframes, right? -Boris
Re: [whatwg] Javascript: URLs as element attributes
On 11/30/10 4:35 AM, Philip Jägenstedt wrote: So far, it seems that the fastest way to reach compat between browsers is to simply not run inline javascript: URLs. One other thing since this is a generic protocol, if we define special-case behavior for it in some cases (e.g. img), that opens up some cans of worms. For example, what should url(javascript:) do in CSS? HTML5 seems like the wrong place to define that -Boris
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 would be more likely to get the security policy right if code paths opted in to JavaScript execution rather than opting out of javascript URL scheme handling. -- Darin
Re: [whatwg] Javascript: URLs as element attributes
On 11/30/10 2:37 PM, Darin Adler wrote: 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 would be more likely to get the security policy right if code paths opted in to JavaScript execution rather than opting out of javascript URL scheme handling. Note that in Gecko, while javascript: is handled as a regular scheme, the handler for it will by default only run in a sandbox and only if the security context is known. The security context is often not known (e.g. for img src it's not known). And running not in a sandbox requires explicit caller opt-in. So the net result is pretty similar. But these are all implementation details. As far as authors are concerned, javascript: is just a protocol like any other, except that trying to load it runs script. Any deviation from this is additional complexity for authors; the further the deviation the more complexity. The question is how much complexity is warranted. Certainly the webkit approach of only running javascript: explicitly for frame/iframe/toplevel documents is simplest on implementors. It'd be pretty easy to get there in Gecko; we'd just remove some code in object and change the default execution policy from sandbox to don't execute. So I agree with Philip that for UAs this is the quickest path to convergence. But is the result what we want for the web platform? -Boris
Re: [whatwg] Please (re)consider explicitly allowing marking up speaker names with cite (new information)
On Fri, 13 Aug 2010, Tantek �~Gelik wrote: Summary: there has been longstanding discussion about the use (or not) of cite to markup names of speakers. From original intent of cite, to references to the Chicago Manual of Style, to the practicality of it just being an alias for i. [...] http://wiki.whatwg.org/wiki/Cite_element#Speaker | | The cite element has been used (and recommended to be used) to | refer to speakers in a conversation, or individuals when quoting them, | thus HTML5 should explicitly permit and encourage this use. | | [snip a number of links to pages that use cite in this way] This has been discussed pretty much to death in the past, including examining existing pages that do this. This proposal does not add new information to the discussion, so I haven't changed the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Additional onxxxx event attributes for DOM Level3 Events
On Mon, 16 Aug 2010, Hajime Morita wrote: I noticed that some events which are defined in DOM Level3 Events [1] don't have associated HTML attributes. For example, keypress event has associated onkeypress attribute. But focusin event doesn't have onfocusin attribute. Here is a list: * wheel event * textInput event * focusin event * focusout event * compositionstart event * compositionupdate event * compositionend event * DOMXxxx events I think these events should have associated attributes defined. DOM mutation events might be better to skip due to its long name and rare usage. But it's just a preference and not a strong opinion. I'm happy to add new event handler attributes, but not to add them just based on completeness. New features are added based on either use cases (i.e. problems that authors or users are facing), or compatibility (i.e. things that browsers already do). If there are specific events for which event handler attributes would be useful, I encourage you to request those specifically, describing either the relevant use cases or citing the existing implementations, as appropriate. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Bluetooth devices
On Mon, 16 Aug 2010, Don Rosen wrote: Is there any intention to provide access to Bluetooth devices through the Device element? Not currently, but it might make sense in the future. The best way to move forward with such a proposal would be to have an experimental implementation show that it is possible, show that it can be done in a secure fashion, show what a reasonable API for it would be, and show that there is author demand for the feature. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for secure key-value data stores
On Tue, 17 Aug 2010, Evan Ireland wrote: I might wish to build an offline web application which will refuse to operate if the browser cannot guarantee that the database is encrypted. Now full-disk encryption would be fine (if the O/S has a power-on password), but how can my web application author detect (using a JS API) if any data stored in a browser's database is in fact encrypted (or not)? It cannot, and should not. It's a user concern. If as a user I want all data that you send me to be printed unencrypted and dropped out of my office window for anyone to read, then I should be allowed to do that. :-) Such uncertainty might force us (as a vendor) to have to develop platform/browser-specific plugins to providew an alternative implemantation of the database API so we can be confident that database storage is secure. Secure from what? On Tue, 17 Aug 2010, Dirk Pranke wrote: I continue to think that the best approach to start with would be to implement a library in JS that did crypto on top of the Platform APIs (and having a native crypto API would be nice as well), and if it turned out to be useful we could roll it into the platform. That is generally the best way forward for any feature, indeed. On Sun, 22 Aug 2010, Brian Campbell wrote: Note that there are several different types of attack you might want to defend against. While it's true that there's no real defense against someone taking physical control of the machine, installing a keylogger, putting the machine back in the users control, and then either uploading the data somewhere or retrieving the data physically at a later time, that attack works against almost all security mechanisms in the web platform (password authentication, HTTPS, cookies, etc). That is a very expensive type of attack, with a high risk of discovery (several opportunities for physical discovery, and the keylogger may be discovered too). It's probably the most wide-spread attack in the real world. There are several attacks that are much cheaper and easier which encryption of data on disk can prevent. I think one of the biggest risks is simply the discarded hard drives. While most places which deal in sensitive data require that hard drives are erased or destroyed before being disposed of, in practice, that's something that's very easy to overlook when discarding an old computer. There is considerable risk of someone just doing dumpster diving being able to recover sensitive data, which can be prevented (with no risk of the password being sniffed) by just encrypting all potentially sensitive data before writing it to the disk. In practice, people having their data read from their discarded disks is far less of a problem than people getting malware installed on their active systems. Also, unless the data is encrypted behind a password prompt and the password is very secure, encryption isn't particularly helpful. I think it's optimistic to hope that browsers will ask all users to enter a secure passphrase before being able to use local storage. The stolen laptop attack is similar; encryption will prevent sensitive data from being leaked, and stealing a laptop is a lot easier than stealing a laptop, installing a keylogger, returning it unnoticed, and then collecting the data from the keylogger unnoticed. Stolen (or lost) laptops are a common problem (though nothing on the scale of malware/keylogger attacks), but that problem is solved by disk-wide encryption with a secure system-wide passphrase, not by a password for local storage. The former, assuming the laptop is stolen while turned off rather than suspended, is a pretty good defence. The latter is almost certainly a worthless defence since the data or key are likely to be found elsewhere in the system (e.g. in the pagefile). So, there are real security benefits to ensuring that sensitive data is stored encrypted. One way to do this is to require the platform to encrypt the data, either the browser itself or the browser ensuring that the operating system has some sort of full-disk encryption. The web app could then require the browser report that data will be encrypted before sending the data down. The problem with this is that browsers may lie, or be mistaken about full-disk encryption. Microsoft Exchange has a flag that notifies the server whether data is stored encrypted, and some companies have policies of not allowing clients that don't support encryption. Of course, this means that several clients just lie, claiming to encrypt the data while not actually doing so (I believe the initial version of the iPhone Exchange client did this, though my memory may be hazy). Indeed. Anyhow, I think most of the reasonable ideas have been suggested in this thread (allow the browser to report whether data will be stored encrypted, provide a JS crypto API to allow web apps to more easily encrypt
Re: [whatwg] Additional onxxxx event attributes for DOM Level3 Events
On 11/30/10, Ian Hickson i...@hixie.ch wrote: On Mon, 16 Aug 2010, Hajime Morita wrote: I noticed that some events which are defined in DOM Level3 Events [1] don't have associated HTML attributes. For example, keypress event has associated onkeypress attribute. But focusin event doesn't have onfocusin attribute. It does in IE. Here is a list: * wheel event `onmousewheel`? That's in IE. * textInput event Following the convention of lc for event handler properties, `ontextinput`? * focusin event * focusout event Those are in IE. * compositionstart event * compositionupdate event * compositionend event * DOMXxxx events I think these events should have associated attributes defined. DOM mutation events might be better to skip due to its long name and rare usage. But it's just a preference and not a strong opinion. I'm happy to add new event handler attributes, but not to add them just based on completeness. New features are added based on either use cases (i.e. problems that authors or users are facing), or compatibility (i.e. things that browsers already do). If there are specific events for which event handler attributes would be useful, I encourage you to request those specifically, describing either the relevant use cases or citing the existing implementations, as appropriate. The reason event handler properties are useful is that they can be detected. A program can make a fair assessment as to whether the element supports the event handler in question and how to handle the case where that isn't supported. That isn't possible with event target; there is no such, `object.generatesEvent`, nor will there be in D3E, according its author. Garrett
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
An update since this topic was discussed on this list before: I updated the vendor-specific syntax a while back to be x-vendor-foo= for content attributes, and .vendorFoo for IDL members; attributes starting with an underscore are also reserved but their use is not encouraged. On Tue, 17 Aug 2010, Tab Atkins Jr. wrote: On Mon, Aug 16, 2010 at 10:27 PM, Anne van Kesteren ann...@opera.com wrote: In fact, iirc we follow the policy that new attribute names will not have hyphens in them, unless it is for some kind of pattern (like data-). Is this supposed to be a general policy? We couldn't determine whether to go with or without dashes when naming an attribute in the bidi meeting a few months ago - current practice seems to go both ways, from a trawl of the attribute index. I don't know that we follow any concrete policy. HTML uses pretty much every naming convention you can come up with _somewhere_. When adding new features generally I just try to find an existing feature with a similar concept and then use the same naming scheme. So e.g. looking at recent additions, bdo suggests bdi, dir= and name= suggest dirname=. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Wed, 01 Dec 2010 00:27:23 +0100, Ian Hickson i...@hixie.ch wrote: An update since this topic was discussed on this list before: I updated the vendor-specific syntax a while back to be x-vendor-foo= for content attributes, and .vendorFoo for IDL members; attributes starting with an underscore are also reserved but their use is not encouraged. If we do .vendorFoo shouldn't we just do vendor-foo=? opera, moz, webkit, ms are unique enough and HTML attributes generally do not use hyphens anyway. (And yes, there will be some more vendors, etc. But over the years there have not been many extensions at all so this is all rather manageable.) -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Feedback on the Atom feed algorithm
On Tue, 17 Aug 2010, Julian Reschke wrote: On 17.08.2010 10:36, Ian Hickson wrote: ... The note is lower down. It reads: Note: The above algorithm does not guarantee that the output will be a conforming Atom feed. In particular, if insufficient information is provided in the document (e.g. if the document does not have anymeta name=author content=... elements), then the output will not be conforming. ... I saw that note. It doesn't mention date handling at all. Indeed, it only mentions one example. I believe the publishing this algorithm the way it is without clearer instructions on what the input needs to contain is a total disservice to the reader. I could see an argument for adding a section that describes what information the algorithm tries to use; is that what you mean? If you think that would be helpful, let me know what information you think should be listed (maybe by going down the algorithm and figuring out what information we currently use) and I'll be happy to add an intro section. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Additional onxxxx event attributes for DOM Level3 Events
Garrett, what you suggest would really be appreciated seen from my point of view and help improve cross-browser coding. If we want to help avoid browser sniffing in user code this is surely a top suggestion. It seems to me that previously proposed solutions like hasFeature() and isSupported() did not get enough support and never reached spread usage among developers. I would like to add that currently oninput, onbeforeunload, onunload events are almost impossible to detect in one or another browser, for this same reason. There should be one suggested (and implemented) way to do these checking in a safe enough manner. Testing for features makes our coding stronger and portable. -- Diego On Wed, Dec 1, 2010 at 12:18 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 11/30/10, Ian Hickson i...@hixie.ch wrote: On Mon, 16 Aug 2010, Hajime Morita wrote: I noticed that some events which are defined in DOM Level3 Events [1] don't have associated HTML attributes. For example, keypress event has associated onkeypress attribute. But focusin event doesn't have onfocusin attribute. It does in IE. Here is a list: * wheel event `onmousewheel`? That's in IE. * textInput event Following the convention of lc for event handler properties, `ontextinput`? * focusin event * focusout event Those are in IE. * compositionstart event * compositionupdate event * compositionend event * DOMXxxx events I think these events should have associated attributes defined. DOM mutation events might be better to skip due to its long name and rare usage. But it's just a preference and not a strong opinion. I'm happy to add new event handler attributes, but not to add them just based on completeness. New features are added based on either use cases (i.e. problems that authors or users are facing), or compatibility (i.e. things that browsers already do). If there are specific events for which event handler attributes would be useful, I encourage you to request those specifically, describing either the relevant use cases or citing the existing implementations, as appropriate. The reason event handler properties are useful is that they can be detected. A program can make a fair assessment as to whether the element supports the event handler in question and how to handle the case where that isn't supported. That isn't possible with event target; there is no such, `object.generatesEvent`, nor will there be in D3E, according its author. Garrett
[whatwg] reflected enumerated attributes feedback
On Tue, 17 Aug 2010, Aryeh Gregor wrote: Actually, it goes further than that. Everyone but IE seems to just return the value of the content attribute when you do a get on the IDL attribute: !doctype html script var el = document.createElement(form); el.setAttribute(method, invalid value); alert(el.method); /script IE alerts get, everyone else alerts invalid value. Are non-IE implementers interested in changing to match IE here? IE's behavior seems more useful. On Mon, 23 Aug 2010, Mounir Lamouri wrote: This is actually a recent change in the specification so you should not expect to have all browsers working the same way. FWIW, Firefox nightlies already follow this change. That will be in beta5 too. Yeah, this area of the spec in general has been in some flux and the implementations are all somewhat away from interoperable. On Thu, 26 Aug 2010, Aryeh Gregor wrote: On Thu, Aug 26, 2010 at 2:00 PM, Ian Hickson i...@hixie.ch wrote: * marquee.direction What do browsers do for this one? Seems like they don't limit it to known values, at least Firefox/Opera/Chrome. Ok. I've left the spec as-is. * meta.httpEquiv I'm pretty sure browsers don't treat this as limited to only known values. * th.scope * textarea.wrap Browsers don't seem to limit these. If we could change all these to limited without compat problems, though, it would be a nice little simplification -- enumerated attributes would all have the same reflection behavior. True, though the interoperability we'd be losing is one of the few bits of interoperability we have in this space! The real question is, would implementing the spec lead to compatibility issues? As Mounir Lamouri pointed out, Firefox nightlies already mostly implement the spec here, so I guess we'll find out. :) The spec is considerably nicer than preexisting behavior. Ok, I've made the change for th.scope. If you could file bugs on getting browsers on board with this that would be great. :-) I haven't changed textareap.wrap because of wrap=off. That value still has the browser put the attribute in the Soft state, but there is some CSS magic that only happens for that value and I am concerned that there will be pages depending on that keyword being detectable. (In particular, changing this would mean that code like textarea.wrap = textarea.wrap could change the layout, which seems bad.) I haven't changed meta.httpEquiv because that one is much more likely to have scripts examining the value irrespective of browser support. Historically, that's been used as a kind of extension point; it being enumerated is relatively recent. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Bluetooth devices
I would repeat, that I think the form of the (logical) wire between the browser and the device is out of scope, and that (effectively) we *do* provide access to bluetooth devices. Heck, my bluetooth keyboard and mouse work today. Connect the devices however you like, we don't care. On Nov 30, 2010, at 15:01 , Ian Hickson wrote: On Mon, 16 Aug 2010, Don Rosen wrote: Is there any intention to provide access to Bluetooth devices through the Device element? Not currently, but it might make sense in the future. The best way to move forward with such a proposal would be to have an experimental implementation show that it is possible, show that it can be done in a secure fashion, show what a reasonable API for it would be, and show that there is author demand for the feature. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Clarifying the use and requirements of Data URL
On Wed, 18 Aug 2010, Peter Beverloo wrote: Currently the specification requires the use of Data URLs for canvas.toDataURL[1] and refers to usage of them a number of times as well[2][3]. While steps describing how to generate a Data URL are defined in the specification[4], they are not being referenced by the other occurrences. These steps seem to be identical to the contents of RFC 2397[5], The data URL scheme by Larry Masinter. [1]�http://www.whatwg.org/specs/web-apps/current-work/#dom-canvas-todataurl [2]�http://www.whatwg.org/specs/web-apps/current-work/#submit-data-post [3]�http://www.whatwg.org/specs/web-apps/current-work/#sandboxOrigin [4]�http://www.whatwg.org/specs/web-apps/current-work/#submit-data-put [5] http://tools.ietf.org/html/rfc2397 The steps you cite as [4] have now been removed. Next to that, the specification does not list when Data URLs should be supported by an User Agent. WebKit, Gecko and Presto seem to accept them as any resource, including locations entered via the address bar, while Trident only accepts Data URLs for images and scripts. That seems out of scope of the specification. Which protocols a user agent supports is a matter for the specifications of those protocols, not a matter for the HTML specification. I believe the use and requirements of Data URLs in the specification could be clarified by: - Referring to RFC 2397 for information about their composition and syntax *or* generalize the steps described in the form submission algorithm[4], so they can be applied on the entire document. I believe proper reference is now made to the RFC wherever relevant. - Extend the accepted values of @src, @href, @action et al to include support for data: URLs. Support for data: is required to the same extent as support for http: is required in those contexts. On Tue, 24 Aug 2010, Julian Reschke wrote: On 18.08.2010 15:21, Peter Beverloo wrote: Currently the specification requires the use of Data URLs for canvas.toDataURL[1] and refers to usage of them a number of times as well[2][3]. While steps describing how to generate a Data URL are defined in the specification[4], they are not being referenced by the other occurrences. These steps seem to be identical to the contents of RFC 2397[5], The data URL scheme by Larry Masinter. I raised http://www.w3.org/Bugs/Public/show_bug.cgi?id=10399, but it appears Ian thinks that not citing RFC 2397 is ok. That was for a different section, which no longer exists (and for which citing the RFC normatively was superfluous, since no normative conformance criteria from the RFC applied to that section). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Clarification on canceling events
On Mon, 23 Aug 2010, Andrew Oakley wrote: Section 7.1.6.1 (Event handlers) says the event must be canceled. This seems a little unclear to me, I assume this means preventDefault() rather than stopImmediatePropagation() or stopPropagation(). This intentionally uses the same terminology as preventDefault()'s definition: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-event-type-preventDefault Is it possible for HTML5 to either reference these parts of DOM Events or more of the language that D3E uses (e.g. say that the default actions should not occur, but propagation continues)? The verb to cancel seems to be the operative terminology used by the DOM3 Events specification for this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Make radio button group suffering from being missing
On 11/29/2010 04:15 PM, Anne van Kesteren wrote: On Thu, 04 Nov 2010 01:20:37 +0100, Mounir Lamouri mounir.lamo...@gmail.com wrote: Currently, when a radio button is required, it will suffer from being missing if no radio elements in the radio button group is checked. However, radio elements in the group will not suffer from being missing if they do not have the required attribute. In other words, if you try to style invalid elements with :invalid, and do: input type='radio' name='s' value='M' required input type='radio' name='s' value='F' only the first element will be styled. I think we should move the requirement to the radio button group that way: The radio button group suffers from being missing if one of the input elements in the radio button group is required and all of them have a checkedness that is false. and radio elements would have this constraint: If the radio button group is suffering from being missing, the element is suffering from being missing.. That way, all radio elements in the same radio button group will have the same validity state. That would be less annoying for authors and error proof while making things clearer (IMO). I'm thinking of implementing that for Gecko 2.0/Firefox 4 so I would like to know if you know any reason that would make the current behavior more appropriate than the one described here. Do you have tests for this by any chance? I agree it makes sense to always treat them as a group. Yes, you can found them in the patch attached to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=610687 -- Mounir
Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable
Did my followup discussion further the case? Do you still feel that I've dismissed your comments regarding IME complexity? I think they were valuable, more as documentation than as cautionary examples... I did understand that you intended the latter, and I recognize the baseline of frustration that my perspective brings. On Nov 28, 2010, at 6:56 PM, Oliver Hunt oli...@apple.com wrote: It _may_ be worth discussing (as I am not all knowing) but I cannot see a way that these APIs could be added without opening up a user to privacy violations. It is somewhat irksome to me that I have raised these exact issues in the past in the context of implementing editors in canvas and you appear to have chosen to ignore me. --Oliver On Nov 27, 2010, at 12:19 PM, Charles Pritchard wrote: Is there room for discussion of an API to expose misspelled ranges of text in contentEditable? This would be building upon the spelling and grammar checking section: http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#spelling-and-grammar-checking A method for a contentEditable section, along the lines of getSpellcheckRanges() would allow for content editors, to stylize and provide further UI controls around spell checking. Such an API could be used to warn the user that they have possibly misspelled text, in a similar way to how word processors convey the information. It may not be feasible at the moment, but it could be worth some discussion. A Range list seems appropriate, though it would need something along the lines of getSuggestedSpelling() on each range. -Charles
Re: [whatwg] Additional onxxxx event attributes for DOM Level3 Events
On 11/30/2010 03:18 PM, Garrett Smith wrote: On 11/30/10, Ian Hicksoni...@hixie.ch wrote: On Mon, 16 Aug 2010, Hajime Morita wrote: I noticed that some events which are defined in DOM Level3 Events [1] don't have associated HTML attributes. For example, keypress event has associated onkeypress attribute. But focusin event doesn't have onfocusin attribute. It does in IE. Here is a list: * wheel event `onmousewheel`? That's in IE. The wheel event is a different, generalized, version of the mousewheel event. As far as I know, no one has implemented it yet. * textInput event Following the convention of lc for event handler properties, `ontextinput`? Last I checked, the DOM3 spec had changed textInput to textinput. Safari and Chrome fire textInput (with a capital I) events but do not currently define an attribute for it. * focusin event * focusout event Those are in IE. * compositionstart event * compositionupdate event * compositionend event * DOMXxxx events Last I checked, the DOMxxx events were all basically being deprecated in D3E. So it would be bad to standardize attributes for those, I think. David I think these events should have associated attributes defined. DOM mutation events might be better to skip due to its long name and rare usage. But it's just a preference and not a strong opinion. I'm happy to add new event handler attributes, but not to add them just based on completeness. New features are added based on either use cases (i.e. problems that authors or users are facing), or compatibility (i.e. things that browsers already do). If there are specific events for which event handler attributes would be useful, I encourage you to request those specifically, describing either the relevant use cases or citing the existing implementations, as appropriate. The reason event handler properties are useful is that they can be detected. A program can make a fair assessment as to whether the element supports the event handler in question and how to handle the case where that isn't supported. That isn't possible with event target; there is no such, `object.generatesEvent`, nor will there be in D3E, according its author. Garrett
[whatwg] Fwd: whatwg Digest, Vol 80, Issue 63
Hi, We need access to Bluetooth devices using the Device element. Without Bluetooth access some of the use cases, specially in the mobile device domain would not be achievable. Saurabh Jain Director SKJ Technologies Private Limited http://www.skjworld.com Author : Mobile Phone Programming using Java ME (J2ME) http://library.skjworld.com/mobile-technology/java/java-me
