[whatwg] 'Applicable Specifications'' Relevance Authors
The definition of an 'applicable specification' is marked as only having relevance for implementations: http://www.whatwg.org/html#other-applicable-specifications I think that the paragraph which defines an applicable specification and the note that follows it are relevant to authors, too -- in particular authors wondering if they can extend HTML. Currently 'HTML5 for Web Developers' has a link 'other applicable specifications' which doesn't go anywhere: http://developers.whatwg.org/elements.html Cheers Smylers
[whatwg] Adding blending to the canvas API
All, I'm working on a spec to add blending and compositing through simple CSS keywords. It is trying to define a generic model that is not specific to Canvas, HTML or SVG and then lists how the model could be implemented. We've gotten some comments that this feature would be useful in Canvas as well so I was wondering if it made sense to add it to the canvas API. I can see 2 ways of adding this: 1. extend the list of compositing operators ( http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#compositing) with blending. This is what is currently in the draft spec ( https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html chapter 7) 2. create a new attribute on the context called 'globalBlendOperation' that takes the same list of blend operations as css ( https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#blend-mode) Any thoughts?
[whatwg] Dialogs and prompts
I just added a bunch of things relating to creating dialogs, popup
windows, inspectors, marking sections of applications as inert, and
related features to make it easier to build Web applications in HTML:
- dialog: an element to mark up windows.
- dialog.show(anchor): a way to show a dialog, anchored to a specific
element on the page.
- dialog.showModal(): a way to make a dialog modal.
- dialog.close(returnValue): a way to close a dialog.
- inert=: a way to disable an entire subtree, without necessarily
making the elements in that subtree appear disabled (e.g. the way that
controls behind a modal dialog are disabled without appearing that
way, in traditional UIs).
- dialog oncancel=: called when the user hits Escape on a modal
dialog, can be cancelled to make the dialog not close.
- dialog onclose=: called when the dialog closes.
- form method=dialog: a way to use form for completely client-side
interactions, including form validation, without having to worry about
the form submitting. (Until browsers support this, you'll have to also
specify something like action=javascript:void(0), unfortunately.)
These features were based on discussions on this list (some of which
are below), but also on the results of looking for existing use cases,
some of which are documented on this wiki page:
http://wiki.whatwg.org/wiki/Dialogs
The Fullscreen specification, also discussed on this list recently,
defines some of the features upon which these are built. Thanks to Anne
and Tantek in particular for working on that spec.
On Tue, 20 Mar 2012, Adam Barth wrote:
On Mon, Mar 19, 2012 at 2:20 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 19 Mar 2012, Jochen Eisinger wrote:
The motivation for this is that in a tabbed browser, modal dialogs
are potentially disrupting the work flow of the user as they can't
interact with any other web site as long as the modal dialog is
displayed.
Current browsers are having problems with the modal prompts:
Chromium for example doesn't display a window created by
showModalDialog in a modal way: http://crbug.com/16045
WebKit and Firefox don't suppress events while a modal dialog is
running: https://bugs.webkit.org/show_bug.cgi?id=78240 and
https://bugzilla.mozilla.org/show_bug.cgi?id=360872
Firefox displays modal prompts as tab-modal. However, it's possible
to execute JavaScript in a tab that should be blocked by a modal
prompt: https://bugzilla.mozilla.org/show_bug.cgi?id=727397 and the
prompts from separate tabs can block each other:
https://bugzilla.mozilla.org/show_bug.cgi?id=727801
All these issues are avoided by dialog's showModal(), which is
intrinsically async (all it does is disable the UI on the rest of the
page).
I'm not sure dialog addresses the same use cases as alert() and
confirm() because dialog is significantly more complicated.
== Non-modal confirm() ==
script
[...]
confirm(Are you sure you want to order the widget?, function(result) {
if (result)
sendOrder();
else
cancelOrder();
});
/script
== dialog ==
dialog id=orderConfirm
form method=dialog
Are you sure you want to order the widget?
input type=button value=Send onclick=sendOrder()
input type=button value=Cancel onclick=cancelOrder()
/form
/dialog
script
[...]
document.getElementById('orderConfirm').showModal();
/script
I don't think it's significantly more complicated, especially given the
gains.
Even after all that, you get a less functional experience in some
respects. For example, on Mac OS X, the Cancel button should be to the
left of the Ok button whereas on Windows they should be ordered as in my
example (i.e., with Ok to the left of Cancel).
Well, on Mac you shouldn't have an Ok button at all, it should be Send
or some such. So this problem exists with confirm() also.
On Tue, 20 Mar 2012, Boris Zbarsky wrote:
Perhaps confirm() should take (optional) labels for the two buttons?
If we were extending confirm(), that might make sense. However, as Maciej
says:
On Wed, 21 Mar 2012, Maciej Stachowiak wrote:
dialog will give a better user experience than even a non-modal
version of window.confirm() or window.alert(). Dialogs that are fully
in-page [...] are the emerging standard for high-quality page-modal
prompting.
I should add that this could be partly for path-dependent reasons, and
that if other technologies had been available, authors might not have
resorted to in-page modality with overlays. But I think the key missing
enabled was not asynchrony but rather the ability to fully control the
UI, layout and available commands of the modal experience.
Indeed. Most of the examples on the wiki page I cite above would be
non-starters with confirm(), even if we extended it with button labels.
alert() is mostly only used by either by sites with a low-quality user
experience, or as as non-production
Re: [whatwg] Dialogs and prompts
On Wed, Apr 11, 2012 at 4:26 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 29 Mar 2012, Darin Fisher wrote: Also, there is a downside to the current convention of custom drawing modal dialogs. Web pages that mash-up content from varied sources would need to have some convention for queuing up dialog requests. Ideally, modal dialogs should be shown in FIFO order rather than all at the same time. This seems like a tricky problem. It seems like something the platform could help with. I believe the dialog proposal helps here. I think non-blocking alert, confirm and prompt helps in a similar vein. The modal variant of dialog handles this (there's a stack of active modal dialogs). Note that dialog's model is FILO, while Darin was asking for FIFO. ~TJ
Re: [whatwg] Adding blending to the canvas API
:-) They are definitely more familiar to designers but they both have their place. On Wed, Apr 11, 2012 at 4:30 PM, Jeremy Apthorp jere...@chromium.orgwrote: On Wed, Apr 11, 2012 at 4:05 PM, Rik Cabanier caban...@gmail.com wrote: All, I'm working on a spec to add blending and compositing through simple CSS keywords. It is trying to define a generic model that is not specific to Canvas, HTML or SVG and then lists how the model could be implemented. We've gotten some comments that this feature would be useful in Canvas as well so I was wondering if it made sense to add it to the canvas API. I can see 2 ways of adding this: 1. extend the list of compositing operators ( http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#compositing ) with blending. This is what is currently in the draft spec ( https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html chapter 7) 2. create a new attribute on the context called 'globalBlendOperation' that takes the same list of blend operations as css ( https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#blend-mode ) Any thoughts? This seems much more useful than the existing composite operations :)
Re: [whatwg] Dialogs and prompts
On Wed, 11 Apr 2012, Tab Atkins Jr. wrote: On Wed, Apr 11, 2012 at 4:26 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 29 Mar 2012, Darin Fisher wrote: Also, there is a downside to the current convention of custom drawing modal dialogs. Web pages that mash-up content from varied sources would need to have some convention for queuing up dialog requests. Ideally, modal dialogs should be shown in FIFO order rather than all at the same time. This seems like a tricky problem. It seems like something the platform could help with. I believe the dialog proposal helps here. I think non-blocking alert, confirm and prompt helps in a similar vein. The modal variant of dialog handles this (there's a stack of active modal dialogs). Note that dialog's model is FILO, while Darin was asking for FIFO. I'm not sure I understand when one would want to queue a dialog to show after another dialog has been closed. Does anyone have an example of that in a Web app today? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Dialogs and prompts
On Wed, Apr 11, 2012 at 6:28 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 11 Apr 2012, Tab Atkins Jr. wrote: Note that dialog's model is FILO, while Darin was asking for FIFO. I'm not sure I understand when one would want to queue a dialog to show after another dialog has been closed. Does anyone have an example of that in a Web app today? Some games I've played on Plus or Facebook, when you first log in for the day, show multiple dialogs for different information, one after another. For example, I might see a dialog for the daily log-in bonus, a dialog for a building that was completed while I was logged out, and a dialog summarizing the results of an attack that some made against me while I was logged out. Since all of these are managed by the same app, it's not difficult for the app to just use their own queue, having each dialog's onclose handler look in the queue and open the next one if it exists. I'm not sure if there's any examples of mashups wanting to do this sort of dialog-ordering. ~TJ
