Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
I must say that I'm a little sad about the fact I have to tie transactions
so closely with undo manager.
In my original proposal where we have AbstractTransaction interface and two
derived interfaces for automatic and manual transactions, I tried to
decouple the concepts of undomanager and transactions so that they can work
independently of each other in the future.
In this ideal world, AbstractTransaction will have pure-virtual apply,
unapply, reapply methods, and undomanager will simply invoke them regardless
of whether a transaction is automatic or not. UAs will simply supply
unapply and reapply methods to AutomaticTransaction internally. So in the
future, we could expose those unapply reapply methods automatically added
by UAs. This will be useful in apps where you want to apply, unapply,
reapply DOM changes without making them user interactive (i.e. without
modifying UndoManager). e.g. readonly mode of Etherpad can make use of this
mechanism.
- Ryosuke
On Mon, Sep 12, 2011 at 6:06 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Sep 12, 2011 at 5:19 PM, Jonas Sicking jo...@sicking.cc wrote:
Could you please supply an example where the apply/reapply split leads
to cleaner or otherwise better code than using a boolean argument?
apply: function() {
// modify dom
// send data back to server
},
unapply: function() {
// ask server what I should do for undo
// modify dom
},
reapply: function() {
// ask sever what I should do for redo
// modify dom
}
I can't give you a code from existing apps because such apps do not use
undoManager API.
Having slightly different signatures for the apply function on both
transaction feels like a much smaller problem. Either we can rename
'apply' on automatic transactions, or we can give it a boolean
argument too which is passed 'false'. It's easy enough to ignore
arguments in JS, simply don't put them in your function signature.
I'm fine with adding a boolean argument if we're splitting the interface
for automatic and manual transactions because then we don't need to have
boolean argument in automatic transaction's apply.
- Ryosuke
[whatwg] including output in form submissions
Hi there, HTML5 does not provide a means of submitting form content that is otherwise rendered as normal text, i.e. not as a form control. The use cases for this are the same as for the output element, but when it is also desirable for the result of a calculation to be sent to the server when the form is submitted. Currently, the only way to implement this is to maintain two copies of the value, one the child text of an output element (or something similar, for example a td or span) and once in the value of an input type=hidden element, using appropriate scripting to keep the two in sync. This is error prone and places an additional burden on the web page author. This can be remedied by allowing the value of output elements to be submitted. That is, include the output element in the submittable form-associated element category. I initially thought that this was precisely what the output element existed for - it was rather surprising when I tried using them but none of the values were appearing in the submission. //Mike -- ⊨ Michael Gratton. ⚙ http://mjog.vee.net/
Re: [whatwg] Proposal for improved handling of '#' inside of data URIs
2011-09-11 00:15 EEST: Daniel Holbert: Browsers handle the # character in data URIs very differently, and the arguably correct behavior is probably not what authors actually want in many cases. This could be more intuitive/do-what-I-mean if we restricted the cases under which # is treated as a fragment-ID delimiter inside of data URIs. In particular: when a # character is followed by or in a data URI, I propose that we *don't* treat the # as a delimiter, and instead just treat it as part of the encoded document. Please, no. We already have WAY too much of do what I mean stuff in HTML and it clearly does not work in the long run. The only sane interpretation of literal # in URI is to use it always as a separator for the fragment identifier. If some user agent does not follow this logic, that user agent should be fixed. When an author writes a data URI for a document that contains a # character, she may unintentionally end up with broken results (or at least inconsistently-handled results), because the # may be treated as the end of the document the beginning of the URI's fragment identifier. When an author writes invalid markup the results should be invalid, too. I agree with WHATWG/HTML5 that defining results for any binary input is required but I think that the spec should not try to second guess the author intention. If the input does not make sense, the output must not make sense. We just need a spec that outputs the *same* output-that-doesn't-make-sense for every user agent. After that the author *will* notice her error and she *will* fix the markup. -- Mikko
Re: [whatwg] including output in form submissions
Hi Mike, I've got some concerns with that:
HTML5 does not provide a means of submitting form content that is
otherwise rendered as normal text
I believe this is the job of CSS rather than HTML - I would say that anything
due to be submitted to the server is semantically an input even if it's styled
as plain text.
Currently, the only way to implement this is to maintain two copies
of the value
I disagree that it's the only way - you could easily use a javascript event
handler on the submit of the form which would go through all output elements
and create input type=hidden elements within the form - this way you're
capturing the 'real output value' at the point of submitting which seems like
it's exactly what you're after. It's worth noting that I'm not much of a fan of
JS workarounds, but I don't see this as a concern because the output value
sounds like it would be created by JS, so a non-JS user would (presumably) not
have any output elems which need converting (in your specific use-case) so
they'd hit your normal server-side fallback for non-JS users.
This can be remedied by allowing the value of output elements to be
submitted.
I would say that this is not helpful - the spec at
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-output-element
states The output element represents the result of a calculation and the
example provided is a calculation between two text fields. The use-case in the
documentation would work fine without JS because the two numbers which are added
together are inputs and would be submitted even though the answer wouldn't be
- this way you can calculate on the server-side directly based on the user's
input (proper semantic usage of input) and the output (semantically output)
is not important to the server.
I would also say that it's specifically unhelpful to send back additional fields
as this will cause cross-browser inconsistencies while it's rolled out (and in
legacy browsers) and cause extra data bloating POST bodies or Query Strings for
what seems to me to be a feature which is not required in what I would see as
the majority of uses of the output element.
To meet your use-case I would recommend one of the following:
a) Using CSS to style the input in an environment where it's semantically
correct to use input (if this plain text rendering is truly an input to be
changed by the user) e.g.
!DOCTYPE HTML
meta charset=UTF-8/
style
input, p{
background: transparent;
border: 0 none;
font-family: sans-serif;
color: #333;
font-size: 14px;
}
input.smallNumber{
width: 1.5em;
display: inline-block;
text-align: center;
}
/style
form action=/
pThere are input name=textInput class=smallNumber type=text
value=5/ people/p
/form
(note: @class smallNumber is a 'small number' (not too large) rather than a
'small field containing a number')
b) Using JS to replace/replicate specific output elems with input
type=hidden on the form submit.
c) Assuming you're accepting user input, then displaying the calculated summary
in an ouptut tag, then you can re-calculate the summary on the server-side
based on the user's input - NOTE: this would be dangerous if the example is
much more complicated than the documented example.
Mat Carey
On 13 September 2011 at 07:29 Michael Gratton m...@vee.net wrote:
Hi there,
HTML5 does not provide a means of submitting form content that is
otherwise rendered as normal text, i.e. not as a form control. The use
cases for this are the same as for the output element, but when it is
also desirable for the result of a calculation to be sent to the server
when the form is submitted.
Currently, the only way to implement this is to maintain two copies of
the value, one the child text of an output element (or something
similar, for example a td or span) and once in the value of an
input type=hidden element, using appropriate scripting to keep the
two in sync. This is error prone and places an additional burden on the
web page author.
This can be remedied by allowing the value of output elements to be
submitted. That is, include the output element in the submittable
form-associated element category.
I initially thought that this was precisely what the output element
existed for - it was rather surprising when I tried using them but none
of the values were appearing in the submission.
//Mike
--
⊨ Michael Gratton.
⚙ http://mjog.vee.net/
Re: [whatwg] Selectors within style scoped
Hi Ian,
given the feedback in this thread it seems to me that limiting selector
matching within style scoped to the scope of the parent element -
including, but not exceeding it - would be a preferred default behavior.
With the addition that the presence of :scope or :root in a selector allows
the matching to exceed the scope, the author also doesn't lose flexibility
when it's needed.
Is it therefore possible to change the spec for style scoped to this new
behavior?
Cheers,
- Roland
On Fri, Jul 22, 2011 at 12:30 AM, simon.mad...@nokia.com wrote:
I've been working with a JS polyfill to enable scoped styles optionally
including or excluding the direct parent element and, from a CSS writing
point-of-view, it feels more natural to be able to affect the parent. The
scoped block essentially has influence over the elements it can directly
'see' - parent and siblings.
Either way, there's going to be a neutral container element so it comes
down to whether that would be better provided by the author of the page or
the author of the included block.
Simon
From: whatwg-boun...@lists.whatwg.org [whatwg-boun...@lists.whatwg.org] on
behalf of ext Kornel Lesiński [kor...@geekhood.net]
Sent: 20 July 2011 22:37
To: a...@ashleysheridan.co.uk
Cc: whatwg
Subject: Re: [whatwg] Selectors within style scoped
On Wed, 20 Jul 2011 20:55:51 +0100, Ashley Sheridan
a...@ashleysheridan.co.uk wrote:
div id=widget
style scoped
#widget foo {}
/style
/div
While I agree that that might be a common pattern, I disagree that it's
actually a good one. Consider an ad service which wraps everything in a
custom div tag. If the scope allowed the immediate parent to be
included as part of the scope, then it could allow the advert to be
altered in a way that could negatively affect the users of the site the
ad appeared on.
The site could wrap the ad in another div to prevent that (and this is
typical when the site wants to create fixed-size ad slot).
The purpose of scope in the style seems to be to protect elements
outside of the included content and to 'contain' the included content
that has the style scoped element in it, presumably because it's
coming from an external source. If you allowed the immediate parent as
your example, then it could allow the 3rd parties who created the advert
to take over the element beyond what the advert service would prefer to
be allowed.
For rogue 3rd parties there's iframe in seamless and sandboxed flavors.
If author is allowing untrusted and misbehaving code in the DOM, then it's
already game over — the ad can do anything, including creating style
without scope and modifying other stylesheets.
Even scoped style could use position:absolute or fixed to modify looks of
something outside the element.
--
regards, Kornel Lesiński
Re: [whatwg] Proposal for improved handling of '#' inside of data URIs
On Sun, 11 Sep 2011 10:21:48 -0400, Michael A. Puls II shadow2...@gmail.com wrote: Encoding the data (markup for example) for the data URI is simple. Just use encodeURIComponent(markup) (on a UTF-8 page) in JS on the data. You still hand-author the markup. You just paste the markup into a textarea and have something (like encodeURIComponent()) percent-encode it for you. For example, http://shadow2531.com/js/create_data_uris.html. (I'll make one for files with the File API at a later date.) -- Michael
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Mon, Sep 12, 2011 at 8:19 PM, Jonas Sicking jo...@sicking.cc wrote: Could you please supply an example where the apply/reapply split leads to cleaner or otherwise better code than using a boolean argument? Boolean arguments are evil and should be avoided wherever possible. It's impossible to figure out from the call signature what they do. Instead, have an argument that accepts a string argument consisting of space-separated tokens, or something like that. Even named constants are better than boolean arguments.
