[whatwg] UndoManager: restoring selection after undoing deletion
Hi, The way selection is restored on WebKit after undoing selection is different from the way it is done on Firefox and Internet Explorer. Say you had hello world and world is deleted by an user. When the user undoes the deletion, WebKit selects world whereas Firefox and Internet Explorer do not select world. WebKit's behavior matches Mac's NSTextView and we probably would like to keep the current behavior. However, there's no easy way for the user agent to figure out whether a given transaction wants to select some contents on undo or not. In fact, we don't even know whether we want to restore selection at all. If an automatic transaction was modifying non-text nodes (e.g. SVG line elements), then restoring selection isn't desirable at all. I can think of two approaches to solve this problem: 1. Let automatic transactions also have unapply/reapply and call them after user agents had done its work, and make the user agent do nothing in regards to selection. We can name them afterUnapply/afterReapply if we want. The benefit of this approach is that it's very general and authors can do other things as well while the disadvantage being author needs to be fully aware of platform-convention of how selection is restore upon undo/redo. 2. Add a boolean restoreSelection and isDeletion properties to the Transaction interface. The user agent restores the selection when the value is true and does not restore selection when the value is false. isDeletion is true when the transaction is meant to delete contents and false otherwise. (Maybe negate the property so that common case will be easy?) The user agents can probably use some heuristics to determine whether a given transaction is deleting contents or not. But I don't like either solution so I'm open to your ideas and thoughts on this. Best, Ryosuke Niwa Software Engineer Google Inc.
Re: [whatwg] UndoManager: better name for Transaction
How about UndoableTransaction? Or DOMTransaction? - Ryosuke On Sat, Sep 10, 2011 at 7:54 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, Ian pointed out that the name Transaction is too generic. Can you think of a better alternative? Best, Ryosuke Niwa Software Engineer Google Inc.
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
Hi all, I've updated the document: http://rniwa.com/editing/undomanager.html Summary of changes: - The undoscope content attribute is now ignored on an editable element unless it is an editing host. Sections 2.1 and 2.2 have been updated to reflect this change. - *Section 3.2 Automatic transactions* was re-organized to clarify details - It now explicitly states that the user agent is not responsible for fully restoring DOM state when interfered by event listeners. - Made highest node affecting an automatic transaction - Ryosuke
[whatwg] Fullscreen revision I
I revised the specification based on the comments thus far: http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html I made the following changes: * The root element is no longer a special case * No longer any attempts at integrating with F11 fullscreen * requestFullscreen() can no longer be invoked when already in element fullscreen * Queued a task to fire an event on a per-document basis (because of cross-origin documents) * Introduced event for requestFullscreen() failure (fullscreenerror) * Improved the wording around requestFullscreen() failure * Removed Document.fullscreen as it's a subset of Document.fullscreenElement I realize this is not what everyone wants. But this seemed the simplest subset of what everyone desired and a pretty good start from where we can enhance going forward. Kind regards, -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Canvas ScrollBar
Hello, Would it be possible to extend canvas specification to include scroll bar functionality? To add scroll bar, to manage scroll bar (total size, page size). Creating control based on canvas that needs scrollbar at this point is unnecessarily difficult at this point. Brona Klucka
Re: [whatwg] Fullscreen Update
2011-10-19 17:45 EEST: Glenn Maynard:
b.onclick = function(e) {
if(document.fullscreen)
document.exitFullscreen();
else
gameDiv.enterFullScreen();
}
In fact, the most obvious code should be
b.onclick = function(e) {
if(gameDiv.fullscreen)
gameDiv.exitFullscreen();
else
gameDiv.enterFullScreen();
}
If F11-fullscreen sets document.fullscreen, this breaks; enterFullScreen
would never be called.
Yes. If the web developer is going to fullscreen a single element, he
should test if that element is fullscreen instead of testing if the
whole document is fullscreen, IMHO.
--
Mikko
Re: [whatwg] Canvas ScrollBar
On Thu, 20 Oct 2011 14:14:12 +0200, Bronislav Klučka bronislav.klu...@bauglir.com wrote: Hello, Would it be possible to extend canvas specification to include scroll bar functionality? To add scroll bar, to manage scroll bar (total size, page size). Creating control based on canvas that needs scrollbar at this point is unnecessarily difficult at this point. Brona Klucka Which is your use case ? It doesn't make any sense at all to me to have scrollbars in a canvas. However, if you need scrolling, you can wrap the canvas with an element with specified dimensions and overflow:auto.
Re: [whatwg] Canvas ScrollBar
On 20.10.2011 14:35, João Eiras wrote: On Thu, 20 Oct 2011 14:14:12 +0200, Bronislav Klučka bronislav.klu...@bauglir.com wrote: Hello, Would it be possible to extend canvas specification to include scroll bar functionality? To add scroll bar, to manage scroll bar (total size, page size). Creating control based on canvas that needs scrollbar at this point is unnecessarily difficult at this point. Brona Klucka Which is your use case ? It doesn't make any sense at all to me to have scrollbars in a canvas. However, if you need scrolling, you can wrap the canvas with an element with specified dimensions and overflow:auto. Hi, 1/ your solution is very wrong solution could you imagine canvas 10x10px? well not possible, only solution is to create smaller canvas, wrap it into overflow auto div with inner div and then compute the dimension of whole image with javascript and transfer it to inner div dimensions (so scrollbars would match) and listen to onScroll event of outer div, and repaint the image with shifted origin 2/ use cases? a) diagram modeller http://www.webnt.cz/demos/033_canvas_diagram/ what if I have some large diagram? b) how about creating user controls using canvas? (rich controls are better doing this way, one has pixel perfect control, full browser compatibility) like document viewer, rich listview/treeview control... Brona Klucka
Re: [whatwg] Fullscreen revision I
The background: black makes a basic case strange: fullscreening
divhello/div will result in black text on a black background. Maybe
having that on video:fullscreen and maybe img:fullscreen makes sense, but it
doesn't seem right in general.
Should margin: 0; padding: 0; be set by :fullscreen?
The current spec doesn't seem to allow asking permission to fullscreen in
advance, since the fullscreen element is set synchronously. This should be
supported; there are a lot of potential problems with the ask-after model
and it shouldn't be the only model supported.
:fullscreen { width: 100%; height: 100%; } will stretch videos and images to
fit the screen, instead of doing something more sensible (letterboxing,
pillarboxing or cropping, depending on aspect ratios and the user or site's
preference). I'm not sure how that should work in general, but
fullscreening a video wouldn't be as simple as video.requestFullScreen().
(I don't recall if video can handle cropping and letterboxing directly;
for example, you don't want to blindly crop a video without the video
knowing about it, or WebVTT subtitles and native controls would get cropped
too.)
On Thu, Oct 20, 2011 at 6:59 AM, Anne van Kesteren ann...@opera.com wrote:
* requestFullscreen() can no longer be invoked when already in element
fullscreen
How do you change the fullscreenElement from one element to another without
exiting fullscreen first? That seems important.
--
Glenn Maynard
Re: [whatwg] UndoManager: better name for Transaction
On Thu, 20 Oct 2011, Ryosuke Niwa wrote: How about UndoableTransaction? Or DOMTransaction? Either works for me. Just pick one and go with it. :-) So long as it's not something that could be very confusingly used by other APIs (or indeed by user code) it doesn't matter to me. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] UndoManager: better name for Transaction
Great. I'd pick DOMTransaction then since my spec is titled UndoManager and DOM Transaction. - Ryosuke On Thu, Oct 20, 2011 at 10:04 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 20 Oct 2011, Ryosuke Niwa wrote: How about UndoableTransaction? Or DOMTransaction? Either works for me. Just pick one and go with it. :-) So long as it's not something that could be very confusingly used by other APIs (or indeed by user code) it doesn't matter to me. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] keygen element
In 4.10.14 The keygen element: Generate an RSA key pair using the settings given by the user, if appropriate, using the md5WithRSAEncryption RSA signature algorithm (the signature algorithm with MD5 and the RSA encryption algorithm) referenced in section 2.2.1 (RSA Signature Algorithm) of RFC 3279, and defined in RFC 2313. [RFC3279] [RFC2313] Wouldn't it be better to at least recommend sha1WithRSAEncryption or better even, sha256WithRSAEncryption, given that MD5 is generally considered as broken? Best regards, Martin Boßlet
[whatwg] Signed XHTML
Dear all, since HTML5 is not finalized yet, I would like to ask if the following would have any chance to be considered for the specification. With TLS we have a great tool for secure communication, we can do privacy and mutual authentication etc. with it. But I have worked on a couple of projects where clients were asking for the possibility to somehow store a receipt of some transaction that took place in their browser. Although we can secure the communication channel, establish identity and authentication with TLS, all the data that is sent back and forth stays ephemeral, with no actual proof of its authenticity and integrity. Those guarantees are only given on the transport channel, but the data itself remains in its original, non-secured form. What those customers wanted was a reliable receipt that could serve as proof of a transaction really having taken place at a certain point in time (both client and server would be potentially interested in such a receipt). At the time, we thought of using XML signatures[1] to sign the XHTML on the server, but signatures could also be applied on the client side - clients could sign the data they submit. Currently we realize such things using smart cards and Java applets on the client side, but this would simplify a lot if we had native Javascript support for smart card access. Clients could download the XHTML signed by the server in order to have some form of transaction receipt. Servers on the other hand would be able to archive the signed data submitted by users and could archive it reliably (by applying timestamps and embedding revocation information), effectively establishing an artifact of the client's commitment to a particular transaction, with the signature guaranteeing a form of non-repuditation. The problem with such a solution currently is that adding a dsig:Signature element unfortunately results in invalid XHTML. In my opinion this could be mitigated simply by importing the XML signature XSD in the XHTML XSD and declaring dsig:Signature as a valid element of XHTML. Of course this feature would be exclusive to XHTML and not applicable to normal HTML. If part of the specification, browsers then could decide to react on the presence of dsig:Signature elements, e.g. by visualizing the presence of a digital signature on the current page, or by offering to download the XHTML in order to store it locally etc. Are there plans in this direction? Would functionality like this have a chance to be considered for the standard? Best regards, Martin Boßlet [1] http://www.w3.org/TR/xmldsig-core1/
Re: [whatwg] Fullscreen revision I
On Thu, 20 Oct 2011 17:10:03 +0200, Glenn Maynard gl...@zewt.org wrote:
The background: black makes a basic case strange: fullscreening
divhello/div will result in black text on a black background. Maybe
having that on video:fullscreen and maybe img:fullscreen makes sense,
but it
doesn't seem right in general.
Should margin: 0; padding: 0; be set by :fullscreen?
The current spec doesn't seem to allow asking permission to fullscreen in
advance, since the fullscreen element is set synchronously. This should
be
supported; there are a lot of potential problems with the ask-after model
and it shouldn't be the only model supported.
:fullscreen { width: 100%; height: 100%; } will stretch videos and
images to
fit the screen, instead of doing something more sensible (letterboxing,
pillarboxing or cropping, depending on aspect ratios and the user or
site's
preference). I'm not sure how that should work in general, but
fullscreening a video wouldn't be as simple as video.requestFullScreen().
(I don't recall if video can handle cropping and letterboxing directly;
for example, you don't want to blindly crop a video without the video
knowing about it, or WebVTT subtitles and native controls would get
cropped
too.)
video already shows the video with correct aspect ratio; it has default
style object-fit:contain. img would be stretched, though. We could make
it object-fit:contain when it's the fullscreen element.
--
Simon Pieters
Opera Software
Re: [whatwg] Fullscreen revision I
On 21/10/2011 4:10 a.m., Glenn Maynard wrote: The current spec doesn't seem to allow asking permission to fullscreen in advance, since the fullscreen element is set synchronously. This should be supported; there are a lot of potential problems with the ask-after model and it shouldn't be the only model supported. I agree, the spec should definitely allow this. We could make requestFullScreen()'s entire body run in a synchronous section, after any permission has been granted? On Thu, Oct 20, 2011 at 6:59 AM, Anne van Kesterenann...@opera.com wrote: * requestFullscreen() can no longer be invoked when already in element fullscreen How do you change the fullscreenElement from one element to another without exiting fullscreen first? That seems important. If you have the fullscreen element as a generic container (div), you can insert your desired fullscreen element as the only child of the actual fullscreen element to get the swap effect. This won't work cross origin, so would prevent (for example) embedded YouTube videos from going fullscreen. I'd prefer for requestFullscreen() while fullscreen to just swap the fullscreen element. However, if we do end up not having requestFullscreen() while fullscreen swap the fullscreen element, then we need to ensure document.fullscreenEnabled returns false while any document is fullscreen. Otherwise video controls won't know to hide their (non-functioning) fullscreen buttons while their document/parent/ancestor documents are fullscreen. Chris Pearce.
