Re: [whatwg] Specification of window.find()
On 05/03/2011 01:42 AM, ext Ian Hickson wrote: I do not know the original use case but I can think of a few: -on mobile devices which have a find dialog but no user interface to access it, make the find dialog appear Are there pages that do this today? Or indeed any UAs that have a find dialog but no UI to access it? [...] I don't really have an interest in defending the feature. I was just hoping to get a specification for the API to get a bit more consistency between engines. Since you do not seem interested in the feature, I guess we can keep it as a WebKit/Gecko extension. Benjamin
Re: [whatwg] Giving the body tag a new meaning.
On 03/01/2011 09:09 PM, ext usuario wrote: I am not proposing the body tag for disappear, but allow it for a new implementation. And perhaps in say 10 years, discontinue it as document start element, when the change be widely spread. The reason? a better semantics advantages. That is a bit weak. You should present solid use cases, especially for big changes... cheers, Benjamin
Re: [whatwg] Unnecessary loading of fallback content in canvas element
On 01/08/2011 12:57 AM, ext Charles Pritchard wrote: Let me know if this has been discussed before: Loading an html page containing: canvasimg src=fallback.jpg //canvas loads the fallback.jpg image, even when canvas is supported. Is this intentional, or simply the easiest route for the moment? I would say that is the indented behavior. If you look at the specification (http://dev.w3.org/html5/spec/the-canvas-element.html), regarding fallback content, you will find that it is still available when Canvas is supported. For example: When a canvas element represents embedded content, the user can still focus descendants of the canvas element (in the fallback content). Since the content is available, I think it is normal for it to follow the normal behavior. cheers, Benjamin
Re: [whatwg] WebWorkers and images
Hi, On 01/07/2011 12:24 PM, ext Berend-Jan Wever wrote: I assume you've discussed this before, but couldn't find any record. Please let me know if there is a document somewhere that explains why WebWorkers have so little access to browser features. I did not see the original discussion but for me this make sense in the scope defined for web workers: This specification defines an API that allows Web application authors to spawn background workers running scripts in parallel to their main page. This allows for thread-like operation with message-passing as the coordination mechanism. Since it is a _message passing_ concurrent system, you should not have to care about concurrent access to objects. To have image manipulation in workers, you would need a way to pass images as messages between the main thread and a worker thread. If it is not already possible, I guess that could be a nice addition to the specification. cheers, Benjamin
Re: [whatwg] Specification of window.find()
On 01/06/2011 10:53 PM, ext Ian Hickson wrote: On Wed, 27 Oct 2010, benjamin.poul...@nokia.com wrote: I would like to suggest a change for the main HTML 5 specification: http://www.whatwg.org/specs/web-apps/current-work/ The problem I have is with the Window object specification (http://www.whatwg.org/specs/web-apps/current-work/#the-window-object ). It does not mention the method find() which can be found on most engines (e.g.: https://developer.mozilla.org/en/DOM/window.find ). It looks like IE doesn't implement this, so it's probably not strictly required for compat with the Web. What are the use cases for this feature? I do not know the original use case but I can think of a few: -on mobile devices which have a find dialog but no user interface to access it, make the find dialog appear -on mobile devices which do not have a find dialog, add one for you document if pertinent -add search feature in a frame. Searching between frames with the browser builtin dialog is usually not doing was user expect On IE, users usually emulate the feature with TextRange http://msdn.microsoft.com/en-us/library/ms535872%28v=vs.85%29.aspx cheers, Benjamin
Re: [whatwg] :invalid
On 12/31/2010 02:13 AM, ext Ian Hickson wrote:
It's not entirely clear to me what the intended UI is here. If the goal is
to only style form elements for (in)validity after they've lost focus or
after their form is submitted, it seems a couple of scripts onform
would be the way to go:
form onblur=event.target.classList.add('examined')
onsubmit=for (var i = 0; i elements.length; i += 1)
elements[i].classList.add('examined')
...along with CSS rules like:
.examined:invalid { ... }
.examined:out-of-range { ... }
On Thu, 23 Sep 2010, Boris Zbarsky wrote:
Are there cases when pages would set invalid default values and want
them flagged as such in UI?
On Fri, 24 Sep 2010, Shiv Kumar wrote:
Typically, in large organizations, there are folks who clean up data. So
they will be presented with data that's already entered by someone else
and their job is to clean up the data. In fact I see the new Form API to
be a very good candidate for this use case.
Indeed.
Isn't that targeting the wrong audience?
I think the use case you solve with .examined:invalid is quite common.
On the other side, batch clean up of data is a special case for
enterprises. And can image those systems validate on server side and
would not benefit much from :invalid.
cheers,
Benjamin
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On 11/25/2010 08:30 AM, ext Nils Dagsson Moskopp wrote: Bijubijumaill...@gmail.com schrieb am Thu, 25 Nov 2010 02:29:31 1. Can we deprecate alert(), confirm(), prompt() ? At present many web2.0 js libs are providing alternate [and cool looking] methods to achieve use cases where we need to use alert(), confirm(), prompt(). So do we need those modal dialogs any longer? If sites rely on them, it is not possible to deprecate them. The specification deprecates some elements that use to be widely used (the elements font, big, center, etc). Deprecating is only a recommendation for authors to not use the feature. I would personally welcome a better alternative to alert(), confirm(), prompt(). Something explicitly page modal and not pseudo-blocking Javascript. Although in my opinion, it would not make sense to deprecate without a good alternative for modal dialogs. cheers, Benjamin
Re: [whatwg] Specification of window.find()
On 11/08/2010 07:57 PM, ext Ian Hickson wrote: On Mon, 8 Nov 2010, Benjamin Poulain wrote: Is writing on this list the correct process make comments about the specification? Yes. What is the best way to see this moving forward? Patience. :-) Thanks for the responses. I will wait for your comments then :) cheers, Benjamin
[whatwg] Specification of window.find()
Hi, I never received an answer for this issue. Is writing on this list the correct process make comments about the specification? What is the best way to see this moving forward? Benjamin On 10/27/2010 11:07 PM, ext benjamin.poul...@nokia.com wrote: Hi, I would like to suggest a change for the main HTML 5 specification: http://www.whatwg.org/specs/web-apps/current-work/ The problem I have is with the Window object specification (http://www.whatwg.org/specs/web-apps/current-work/#the-window-object ). It does not mention the method find() which can be found on most engines (e.g.: https://developer.mozilla.org/en/DOM/window.find ). I think it would be good to have it in the standard, and to define a standard behavior for it. WebKit and Gecko have small differences in the way this function is implemented. I recently stumbled upon the way this function handle content invisible because of clipping: https://bugs.webkit.org/show_bug.cgi?id=15078 I think the best way to handle this case would be not to select the hidden strings. This would be the less disruptive for Web developers, and would make sense for the user interface. In any case, I would prefer this function to be part of a standard instead of having a behavior specific to WebKit. Best regards, Benjamin
