[selectors-api] Feature Requests for Version 2
Hi, I've started keeping track of all the feature requests for Selectors API 2 in Bugzilla. http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Selectors+API I'll start investigating these features after I get the major issues in the current spec sorted out. If anyone has more information, particularly use cases or documentation of how existing JS libraries handle those features, please comment on the relevant bug. Or if you have any other feature requests, file a new bug. http://www.w3.org/Bugs/Public/enter_bug.cgi?bug_severity=enhancementcomponent=Selectors%20APIproduct=WebAppsWG -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Accessibility requirement
Hi Cynthia, On Fri, Jul 11, 2008 at 9:50 PM, Cynthia Shelly [EMAIL PROTECTED] wrote: Hi, I'm a member of wai-pf and wcag, and met some of you at the web apps face to face in redmond recently. I was reading through the widgets 1.0 requirements spec, and came across this accessibility requirement. Wondering why only should and may here, and not must? the reason we have should and may is to accommodate HTML, which is not as accessible as it could be. To have must would mean that HTML4.01 could not meet the requirement. R37. Language Accessibility A conforming specification must specify that the language used to declare the user interface of a widget be either HTMLhttp://www.w3.org/TR/widgets-reqs/#html or a language that is accessible at various levels: it should provide keyboard access to interactive graphical elements, and provide means to access the widget's functionality through an non-graphical UI. The declared interface may also be accessible to screen readers, allowing relevant sections of text and functionality to be accessed by non-visual means. Also, I noticed references to google and yahoo web gadgets documentation, and wondered if you'd seen the Windows Live Gadgets SDK [1]? We have, however the spec does not address the requirements of web widgets, such as iGoogle Gadgets or Windows Live Gadgets. Please see the Widgets Landscape document [1] for differences between web widgets and widgets as understood by the Working Group. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-land/ -- Marcos Caceres http://datadriven.com.au
Re: [selectors-api] What DOM feature Selectors API belongs to?
On Jul 14, 2008, at 8:15 AM, Lachlan Hunt wrote: Boris Zbarsky wrote: On Mon, 14 Jul 2008 03:40:44 +0200, Lachlan Hunt [EMAIL PROTECTED] wrote: Would it be acceptable if I defined one, but made it optional for implementers to support? Or at least optional for ECMAScript implementations? That way an implementation can choose to support it if feature detection is necessary for the language and there is no other way to do it. What's the point of making the feature string optional, exactly? To avoid forcing implementers to bother implementing such a useless feature, and potentially lying about their support. Basically, this should only be for languages other than ECMAScript that don't have other detection mechanisms available, and where the programmer isn't always in control of which DOM implementation is in use where the program is run. (If the programmer is in control of that, then feature detection is useless since they can just check the documentation) Since implementing the feature string is trivial, I'd rather it be mandatory. I agree that feature strings are not a great mechanism, but optional features are a greater harm than feature strings. Regards, Maciej
Re: [selectors-api] What DOM feature Selectors API belongs to?
On Mon, 14 Jul 2008 20:26:23 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: Since implementing the feature string is trivial, I'd rather it be mandatory. I agree that feature strings are not a great mechanism, but optional features are a greater harm than feature strings. When I originally proposed this to Lachlan I suggested making it a feature for non-ECMAScript implementations. I agree that making it optional is not good. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] What DOM feature Selectors API belongs to?
Maciej Stachowiak wrote: On Jul 14, 2008, at 8:15 AM, Lachlan Hunt wrote: To avoid forcing implementers to bother implementing such a useless feature, and potentially lying about their support. Basically, this should only be for languages other than ECMAScript that don't have other detection mechanisms available, and where the programmer isn't always in control of which DOM implementation is in use where the program is run. (If the programmer is in control of that, then feature detection is useless since they can just check the documentation) Since implementing the feature string is trivial, I'd rather it be mandatory. I have now added a mandatory feature string. http://dev.w3.org/2006/webapi/selectors-api/#dom-feature -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Investigating NSResolver Alternatives
On Mon, 14 Jul 2008 21:30:18 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: How do I select all the inline SVG images on the page? div svg, p svg though it's not quite as thorough as your solution. Offhand, you're missing td, span, body to cover any sort of decent range of images But yes, much less thorough, indeed. And hard to get right. True. On the other hand, this seems extremely complex to author and not something most authors would come up. :-) That's possible, but I would think that the authoring of the query would be by one of the various toolkits, and the author would call getSVGImages() or some such. Ok. If this is the kind of scenario we're trying to get NSResolver defined for it does not be worth it. Last I checked, the main envisioned use of the querySelector* APIs was to speed up existing queries toolkits do. Might be worth asking them what they think would be useful. http://krijnhoetmer.nl/irc-logs/whatwg/20080709#l-597 http://api.dojotoolkit.org/jsdoc/dojo/HEAD/dojo.query (It doesn't even do XML unless all names are lowercase.) http://www.prototypejs.org/api/utility/dollar-dollar I agree that asking them explicitly would be good though, but it seems like so far the need was not compelling enough to implement it. (And libraries generally have gone to extreme lengths to implement other things not natively supported by browsers or not available cross browser.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
