Re: [whatwg] Feedback on UndoManager spec
On Wed, Oct 26, 2011 at 9:06 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Oct 26, 2011 at 8:21 PM, Jonas Sicking jo...@sicking.cc wrote: Why is it problematic to move an element with an undoManager from one document to another. If all the data that the undomanager needs lives inside the undoManager object itself, it seems quite possible to move between documents or even interact with while not inside a document. The problem is that if the undo manager has automatic transactions in them, then they'll have references to nodes to undo/redo transactions. But those nodes's owner document is still that of the old document. At least in WebKit, this will be a bit of an issue. The way that the DOM4 spec is written these days, those nodes will get automatically adopted when they are inserted into the new document. If webkit has limitations around that, those limitations needs to be fixed anyway in order to implement DOM4 correctly. Note that the upcoming mutation observer spec makes no difference between nodes in a document and nodes which are not. So if the undoManager uses the same backend, or is even built on top of it, then things will just automatically work. I thought about implementing UndoManager on top of new DOM mutation observer API, but the asynchronous nature of new notification API makes it a little hard, if not impossible, to implement UndoManager's synchronous API correctly. In Gecko we're implementing both specs on the same synchronous backend. You're right that implementing on top of the notification API is likely going to be hard. / Jonas
Re: [whatwg] New attributes would degrade better than new elements
27.10.2011 5:38, Eric Sh. wrote: And if we stop adding new features old browsers do not support or not use them because very little browsers are not supporting them then it would completely stop innovation and the evolution of the web. How does this relate to the question of adding element vs. adding attributes? I am supporting what Ashley has said, just think about it if you sorround context with article then speech browsers can know from where to start reading the article instead of a whole web page. They could do just the same with div type=article. I believe that the decision makers are not stupid, _I_ am not stupid, and I did not come to think of this earlier. they are smart enough to know all these technical issues and conflicts There are issues and conflicts with adding a new element like nav, as compared with adding a new attribute. So the question is: what do you gain by adding an element rather than an attribute? There is no _required_ functionality or default rendering for nav or article and no special attributes for them. What you lose by having them as elements rather than attributes is that you cannot style them in a manner that works on all browsers. And lastly, I understand and encourage different opinions but I think it is too late to change anything that has been already implemented by all major browsers(Including IE 9!) Do you think that older versions of IE can be ignored? They will be with us for years. There are ways to teach new elements to them, but they are based on JavaScript (so they do not work universally). Such issues would be quite unnecessary if attributes were used and not elements. There's no implementation worth mentioning so far, or can you mention a single browser or search engine that actually does something useful with, say, article? Don't you think it would be triviality to its authors to extend the feature to cover div type=article? The only real argument in favor of elements is brevity, and it should not weigh much when compared with compatibility issues. This is also a matter of future additions. When new markup features will be added, will they be designed to degrade gracefully and to allow smooth transition? If, for example, it will be decided that dedicated markup for the main content of a document is needed after all, adding a new element like main.../main would have the same problems as nav, article, etc. now have. It would be much smoother to introduce div type=main.../div, and taking the new feature into use in old documents would require just the addition of one attribute - not changing the existing markup like div id=main.../div to another element (potentially requiring many changes to CSS and scripts) or redundantly using both the old markup and the new element around it. This is different from standardizing class attribute values. Such standardization is questionable, since the class attribute is supposed to be authors' playground, mainly for styling, and assigning a meaning to any reasonable-looking class name would conflict with existing usage. So it's better to keep class free for authors' varying purposes and use a different attribute, with no prior use, to introduce new semantics. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Feedback on UndoManager spec
On Wed, Oct 26, 2011 at 11:06 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Oct 26, 2011 at 9:06 PM, Ryosuke Niwa rn...@webkit.org wrote: The problem is that if the undo manager has automatic transactions in them, then they'll have references to nodes to undo/redo transactions. But those nodes's owner document is still that of the old document. At least in WebKit, this will be a bit of an issue. The way that the DOM4 spec is written these days, those nodes will get automatically adopted when they are inserted into the new document. If webkit has limitations around that, those limitations needs to be fixed anyway in order to implement DOM4 correctly. Interesting. I've done some quick testing but maybe problems I had in mind no longer exist in WebKit. We do a poor job on node adoption and lifetime control so this might be a good opportunity to sort them out anyway. - Ryosuke
Re: [whatwg] New attributes would degrade better than new elements
On Thu, 2011-10-27 at 09:28 +0300, Jukka K. Korpela wrote: 27.10.2011 5:38, Eric Sh. wrote: And if we stop adding new features old browsers do not support or not use them because very little browsers are not supporting them then it would completely stop innovation and the evolution of the web. How does this relate to the question of adding element vs. adding attributes? I am supporting what Ashley has said, just think about it if you sorround context with article then speech browsers can know from where to start reading the article instead of a whole web page. They could do just the same with div type=article. Well, the div tag hasn't been around since the beginning, so someone obviously thought it was useful enough to warrant being added. At the time it was added there were two main browsers IE and Netscape Navigator. IE supported div and Netscape supported layer, and both had a fairly good market share. Were the specs stupid for picking one they thought was useful and going with it? I believe that the decision makers are not stupid, _I_ am not stupid, and I did not come to think of this earlier. they are smart enough to know all these technical issues and conflicts There are issues and conflicts with adding a new element like nav, as compared with adding a new attribute. So the question is: what do you gain by adding an element rather than an attribute? There were issues when HTML4 came along and added a bunch of new tags, IE was still not handling acronym and abbr the same until a while ago, which is probably why acronym was dropped. There is no _required_ functionality or default rendering for nav or article and no special attributes for them. What you lose by having them as elements rather than attributes is that you cannot style them in a manner that works on all browsers. nav is a block level element, so behaves as such in conforming browsers. And lastly, I understand and encourage different opinions but I think it is too late to change anything that has been already implemented by all major browsers(Including IE 9!) Do you think that older versions of IE can be ignored? They will be with us for years. There are ways to teach new elements to them, but they are based on JavaScript (so they do not work universally). Such issues would be quite unnecessary if attributes were used and not elements. Like I said before, if someone is using an older version of IE, it's also likely that they will not have Javascript turned off. Nobody uses an older version of IE by choice, if they knew another browser existed they would use it. If they're in an environment where they can't change it but want to, the last thing they'll do is block what little chance they have of seeing the modern web. There's no implementation worth mentioning so far, or can you mention a single browser or search engine that actually does something useful with, say, article? Don't you think it would be triviality to its authors to extend the feature to cover div type=article? The only real argument in favor of elements is brevity, and it should not weigh much when compared with compatibility issues. What about strong and b? The former tag is what we have been told to use going forward because of the context it adds, and this is true. Google admits certain aspects of its indexing algorithm, and this is but a little part of it. They would be certainly missing a trick if they weren't also indexing based on HTML5 tags as well, adding context to a page. Think about it, they can now identify key areas of your page if you've marked it up correctly, which you can't do with HTML4. This is also a matter of future additions. When new markup features will be added, will they be designed to degrade gracefully and to allow smooth transition? If, for example, it will be decided that dedicated markup for the main content of a document is needed after all, adding a new element like main.../main would have the same problems as nav, article, etc. now have. It would be much smoother to introduce div type=main.../div, and taking the new feature into use in old documents would require just the addition of one attribute - not changing the existing markup like div id=main.../div to another element (potentially requiring many changes to CSS and scripts) or redundantly using both the old markup and the new element around it. What is the fear of adding new tags? You don't create a new XML document with every tag as tag do you? For that same reason it makes sense to use different tags for HTML elements. They are backwards compatible in that browsers that don't understand them can just ignore them. You can use other elements within them in a transitional phase of your development if you really think you need to. This is different from standardizing class attribute values. Such standardization is questionable, since the class attribute is
Re: [whatwg] New attributes would degrade better than new elements
27.10.2011 9:55, Ashley Sheridan wrote: There is no _required_ functionality or default rendering for nav or article and no special attributes for them. What you lose by having them as elements rather than attributes is that you cannot style them in a manner that works on all browsers. nav is a block level element, so behaves as such in conforming browsers. And if div type=nav were used, it would be rendered as a block in nonconforming browsers too. (The point about more or less required default rendering with display: block is taken as a correction to my statement above, but it does not really change my point. Rather, strengthens it.) What about strong and b? Yes, what about them? They have been in HTML since the very beginning. If you were to add _new_ markup for emphasis into HTML, I would suggest that you don't add a new element, like key, but rather an attribute - to an element that comes closest in meaning and default rendering, like strong type=key or b type=key. Google admits certain aspects of its indexing algorithm, and this is but a little part of it. They would be certainly missing a trick if they weren't also indexing based on HTML5 tags as well, adding context to a page. There's a lot we can speculate about potential use of the new markup elements and remarkably little factual evidence. But surely if Google can recognize nav and make some use of it, it could deal with div type=nav as well. What is the fear of adding new tags? Compatibility with older browsers. It should not be broken without due cause. You don't create a new XML document with every tag as tag do you? HTML isn't XML. Or, to the extent that it is XML (serialized as XML), it has a specific HTML vocabulary recognized by browsers and other HTML-aware software. They are backwards compatible in that browsers that don't understand them can just ignore them. That's exactly the point that causes the incompatibility: to a browser that does not recognize nav at all, your CSS settings for it are ignored and it isn't even rendered as a block by default. You can use other elements within them in a transitional phase of your development if you really think you need to. So in any reasonable use now or some years from now, the new markup that was supposed to simplify markup will make markup more lengthy and less logical. Instead of div class=nav.../div authors would need to use navdiv class=nav.../div/nav and they would have to do all the styling and scripting on the div element. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] New attributes would degrade better than new elements
On Wed, 26 Oct 2011 23:36:23 +0200, Jukka K. Korpela jkorp...@cs.tut.fi wrote: So, it's not a big deal. It's difference between working on all browsers and working on some browsers as well as being tweakable when JavaScript is enabled. div type=nav is not stylable in IE6 because it doesn't support attribute selectors. -- Simon Pieters Opera Software
Re: [whatwg] New HTML5 Form type
I very much encourage this idea. I fret frequently when I see the unsupported features of the HTTP protocol not being used because of missing support in browsers and servers. Like the PUT and DELETE. And this enchancement of the AUTH. A more seamless integration of the HTTP AUTH to the client side of the HTTP protocol as suggested in the letter in which I'm replying to would be great. This is my humble oppinion as a young web-developer. Best regards Robin G. Aaberg Last year student in Communication technology @ Bergen University College Proud member of Communica. On Sun, Oct 23, 2011 at 3:47 AM, Michael Herold her...@physik.fu-berlin.dewrote: Hello, i want to discuss some thoughts on the html form element (see below). If somebody thinks this idea might be useful I would continue to check how a implementation of this feature would be possible and what the technical difficulties would be. I have no idea if there is a way to bring this to HTML5 or commit this in any other way to the W3C. Best wishes, Michael **Suggestion** Add a new possible value auth to the HTML form //method// attribute. If input elements named username/password are present they are used to authenticate. Otherwise the first input element is used as username and the first input[type=password] element is used as password. It may be useful to interact with the http-status as the browser needs a //nonce// for digest auth. The aim would be to create custom login and logout dialogs without JavaScript. **Thoughts regarding authentication** Today there are three common ways to authenticate using HTTP: GET, cookies, HTTP-Auth. **GET** Putting a session (+user) in the get. - copy+paste and visual access can steal login - have to depend on users ip to add a bit of security - supported by every browser - the website has to adjust every link for every user - the url gets unreadable **cookies** Putting a session (+user) in a cookie. - can be implemented with sufficient security - broken by standard (none standard SLD fix in every browser) - disabled or not supported by many clients for various reasons - leaves footsteps on hdd per definition **HTTP-Auth** Basic or Digest Access Auth - can be implemented with sufficient security - the right way to authenticate - the browser may give the user the full controle/overview over page logins - very simple to set up **Thoughts regarding HTML** By now the HTML(5) form element only supports two different values for the method attribute, namely get and post. As the abstract meaning of the method attribute -as far as i know- is not defined, one may suppose that this attribute defines the way how the form data are used for a HTTP request. If we take this definition, one may enhance the method element to other features of the HTTP protocol. These are some of the features that are used to shared data: - GET - POST - Auth - Cookies As cookies are working in the other direction, we may exclude them from our list for this purpose.
Re: [whatwg] New attributes would degrade better than new elements
27.10.2011 11:42, Simon Pieters wrote: It's difference between working on all browsers and working on some browsers as well as being tweakable when JavaScript is enabled. div type=nav is not stylable in IE6 because it doesn't support attribute selectors. Granted, but a) IE6 is dying, whereas IE7 and IE8 are and will be with us for a long time, and they do support attribute selectors b) if you regard IE6 as still relevant, you can additionally use a class or id attribute (or keep it, if working with an existing document); on IE6, they work for div but not for nav as the entire element is unknown. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] New attributes would degrade better than new elements
How does this relate to the question of adding element vs. adding attributes? I am saying that they also added div which is the most famous tag to date(added in HTML 4), so maybe we should have used tag type=div and tag type=img that way all browsers would support it no? They could do just the same with div type=article. Don't you think that it rather lengthy way of saying the same thing? _I_ am not stupid, and I did not come to think of this earlier. Did I say you were? All I said is that you are underestimating the knowledge of the specification makers throughout the years. What is the fear of adding new tags? Compatibility with older browsers. It should not be broken without due cause. They are backwards compatible in that browsers that don't understand them can just ignore them. That's exactly the point that causes the incompatibility: to a browser that does not recognize nav at all, your CSS settings for it are ignored and it isn't even rendered as a block by default. It looks like you missed the part of http://ejohn.org/blog/html5-shiv/ where it shows you that styling DOES work on browses without HTML 5 support. And the number of browsers who do not support HTML 5 tags and have javascript disabled is far too little in my opinion for any website to try and support. b) if you regard IE6 as still relevant, you can additionally use a class or id attribute (or keep it, if working with an existing document); on IE6, they work for div but not for nav as the entire element is unknown. If you create the element using javascript then the tag name IS known and styleable. From what it looks like your solution only makes html documents bigger and harder to write(not to mention the pains of css and attributes across browsers), and also against the entire HTML history where the tag name is used(almost always) to define it's contents and not one of it's attributes. And the more time you keep having support for too old browsers the harder it is for web developers to keep up with all browsers and advance the web and make it better. Do you think we should have elements like menu and canvas as div type=menu and div type=canvas? And last thing - what can we do with browsers that already support this? This is a major technical problem and you haven't said anything on this front.
Re: [whatwg] New attributes would degrade better than new elements
Jukka K. Korpela jkorp...@cs.tut.fi wrote: 27.10.2011 9:55, Ashley Sheridan wrote: There is no _required_ functionality or default rendering for nav or article and no special attributes for them. What you lose by having them as elements rather than attributes is that you cannot style them in a manner that works on all browsers. nav is a block level element, so behaves as such in conforming browsers. And if div type=nav were used, it would be rendered as a block in nonconforming browsers too. (The point about more or less required default rendering with display: block is taken as a correction to my statement above, but it does not really change my point. Rather, strengthens it.) What about strong and b? Yes, what about them? They have been in HTML since the very beginning. Erm, what?! b might have been there from the beginning, but strong was only added in HTML4, the same time acronymwas, and IE didn't support that at the time. If you were to add _new_ markup for emphasis into HTML, I would suggest that you don't add a new element, like key, but rather an attribute - to an element that comes closest in meaning and default rendering, like strong type=key or b type=key. Google admits certain aspects of its indexing algorithm, and this is but a little part of it. They would be certainly missing a trick if they weren't also indexing based on HTML5 tags as well, adding context to a page. There's a lot we can speculate about potential use of the new markup elements and remarkably little factual evidence. But surely if Google can recognize nav and make some use of it, it could deal with div type=nav as well. What is the fear of adding new tags? Compatibility with older browsers. It should not be broken without due cause. There is good cause. If we pandered to old browsers (IE) then we would be years behind where we are now. It was only because of efforts like Firefox that IE started to make an effort with their browser again. It sounds elitist, and I am to a point, but there has to be a time when developers just say enough is enough and move forward with the web in a way that is beneficial to the majority of people. Just look at the stats at w3schools. You don't create a new XML document with every tag as tag do you? HTML isn't XML. Or, to the extent that it is XML (serialized as XML), it has a specific HTML vocabulary recognized by browsers and other HTML-aware software. They are backwards compatible in that browsers that don't understand them can just ignore them. That's exactly the point that causes the incompatibility: to a browser that does not recognize nav at all, your CSS settings for it are ignored and it isn't even rendered as a block by default. Prompting the user to ask themselves why things look strange and make an effort to upgrade their browser. You can use other elements within them in a transitional phase of your development if you really think you need to. So in any reasonable use now or some years from now, the new markup that was supposed to simplify markup will make markup more lengthy and less logical. Instead of div class=nav.../div authors would need to use navdiv class=nav.../div/nav Not really, you don't have to give every element you style a class of its own. and they would have to do all the styling and scripting on the div element. As mentioned before, html shiv allows Javascript to makeold IE aware of the new elements. You can say they turn off script, but you won't give an example of someone using an old IE that would do that. -- Yucca, http://www.cs.tut.fi/~jkorpela/ Thanks, Ash http://www.ashleysheridan.co.uk -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: [whatwg] Signed XHTML
On Thu, Oct 20, 2011 at 9:57 PM, Martin Boßlet martin.boss...@googlemail.com wrote: Are there plans in this direction? Would functionality like this have a chance to be considered for the standard? The chances are extremely slim. XML signatures depend on XML canonicalization which is notoriously difficult to implement correctly and suffers from interop problems because unmatched sets of bugs in the canonicalization phase make signature verification fail. I think browser vendors would be reasonable if they resisted making XML signatures of canonicalization part of the platform. Moreover, most of the Web is HTML, so enthusiasm for XHTML-only features is likely very low these days. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Feedback on UndoManager spec
On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa rn...@webkit.org wrote:
I meant properties authors added to nodes. e.g.
span.myProperty = true;
Should span be removed by some automatic transaction, authors may expect it
to be restored on undo.
That sounds like the ideal behavior, unless it's too difficult to
implement. If authors just used Node.dataset, that would solve their
problem, but it would be better to behave as expected to start with.
The assumption is transaction works like a regular object unless otherwise
stated. I guess I can cite your example though.
Some APIs copy objects in some way instead of maintaining a reference.
For instance, in WebKit, Selection.getRangeAt() doesn't return the
same object you added with Selection.addRange() (although the spec
currently says it should). It seems best to be explicit.
But this doesn't define what happens in the face of manual
transactions. Also, it's not precise even if there are no manual
transactions.
UAs don't do anything for manual transactions. They just call
unapply/reapply.
I mean, if there's a mix of automatic and manual transactions, and the
manual transactions don't restore the exact same DOM, nothing says how
the UA should unapply/reapply the automatic transactions. It just
says the user agent still must do its best effort to restore the DOM
state.
What's the use-case for manual transactions anyway? I'm sure it's
been discussed, but your spec doesn't say. It could use an example.
This is well defined in terms of DOM state. The spec says UAs should restore
the DOM state
so it all depends on how DOM state is defined.
I also vaguely remember Ehsan telling me Gecko might have a trouble
restoring the exactly same object
on undo/redo because of the way its undo and redo are implemented.
Well, at some point we want to make sure we have interop if possible,
unless it's really performance-critical that this be UA-dependent.
The same is true for having apply and reapply. Jonas wanted to get rid of
reapply altogether and just have
void apply(in boolean isReapply)
In this world, you could do
{ apply: function(isReapply) { return isReapply ? this.doApply() :
this.doReapply(); } }.
I didn't want this API because I'd expect apply and reapply to be
substantially different.
I think either one of those two APIs would be fine. I don't think the
compromise is good, because it gives authors two ways to do the same
thing, which is confusing. I don't know which API is better without
knowing the use-cases for manual transactions. But Jonas' version is
more flexible, because if the two are substantially different you can
always just do
{ apply: function(isReapply) {
if (isReapply) {
// reapply logic
} else {
// totally separate apply logic
}
}, . . . }
which is really no harder to write than
{ apply: function() {
// apply logic
}, reapply: function() {
// totally separate reapply logic
}, . . . }
It's only one or two lines longer, and one level of indent greater.
So I don't think a separate reapply member of the dictionary is
useful. It just makes things more complicated, even if most of the
time the logic will be totally separate.
On Thu, Oct 27, 2011 at 2:44 AM, Ryosuke Niwa rn...@webkit.org wrote:
Interesting. I've done some quick testing but maybe problems I had in mind
no longer exist in WebKit. We do a poor job on node adoption and lifetime
control so this might be a good opportunity to sort them out anyway.
FWIW, I've noticed WebKit doesn't always do adoptions correctly. For
instance, Range.setStart() will throw if the node you pass is from a
different document than the range, when the spec says it should
succeed. I think I've noticed this for some Node methods too. The
general rule in the specs these days is anytime you reparent a node to
another document, it gets silently adopted.
Re: [whatwg] Feedback on UndoManager spec
On Thu, Oct 27, 2011 at 10:48 AM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa rn...@webkit.org wrote:
The same is true for having apply and reapply. Jonas wanted to get rid of
reapply altogether and just have
void apply(in boolean isReapply)
In this world, you could do
{ apply: function(isReapply) { return isReapply ? this.doApply() :
this.doReapply(); } }.
I didn't want this API because I'd expect apply and reapply to be
substantially different.
I think either one of those two APIs would be fine. I don't think the
compromise is good, because it gives authors two ways to do the same
thing, which is confusing. I don't know which API is better without
knowing the use-cases for manual transactions. But Jonas' version is
more flexible, because if the two are substantially different you can
always just do
{ apply: function(isReapply) {
if (isReapply) {
// reapply logic
} else {
// totally separate apply logic
}
}, . . . }
which is really no harder to write than
{ apply: function() {
// apply logic
}, reapply: function() {
// totally separate reapply logic
}, . . . }
It's only one or two lines longer, and one level of indent greater.
So I don't think a separate reapply member of the dictionary is
useful. It just makes things more complicated, even if most of the
time the logic will be totally separate.
I disagree. I think the boolean makes things more complicated. Boolean
arguments stink. Every time you want to use this API you need to go look up
the documentation to remember whether the boolean is isReapply or
isApply. There's no such confusion if you have a separate method.
You can easily get the same semantics and code reuse with a simple helper
function. I clearly have a preference for having an *optional* reapply
method, but I agree that the current compromise is worse than either
individual option.
function myApply(isReapply) { }
{
apply: function() { myApply(false); },
reapply: function() { myApply(true); }
}
On Thu, Oct 27, 2011 at 2:44 AM, Ryosuke Niwa rn...@webkit.org wrote:
Interesting. I've done some quick testing but maybe problems I had in
mind
no longer exist in WebKit. We do a poor job on node adoption and lifetime
control so this might be a good opportunity to sort them out anyway.
FWIW, I've noticed WebKit doesn't always do adoptions correctly. For
instance, Range.setStart() will throw if the node you pass is from a
different document than the range, when the spec says it should
succeed. I think I've noticed this for some Node methods too. The
general rule in the specs these days is anytime you reparent a node to
another document, it gets silently adopted.
This is a known bug. I just haven't gotten around to fixing it. Except for a
bug in our nascent shadow dom implementation, this is the only case where
WebKit still throws a wrong document error.
http://codesearch.google.com/codesearch#search/exact_package=chromiumq=WRONG_DOCUMENT_ERR%20file:(%5C.h%7C%5C.cpp)$type=cs
Re: [whatwg] Feedback on UndoManager spec
On Thu, Oct 27, 2011 at 2:28 PM, Ojan Vafai o...@chromium.org wrote: I disagree. I think the boolean makes things more complicated. Boolean arguments stink. Every time you want to use this API you need to go look up the documentation to remember whether the boolean is isReapply or isApply. There's no such confusion if you have a separate method. I agree with that. Having separate apply/reapply arguments is cleanest. But having both that and an isReapply argument is the worst of all possible worlds. This is a known bug. I just haven't gotten around to fixing it. Except for a bug in our nascent shadow dom implementation, this is the only case where WebKit still throws a wrong document error. http://codesearch.google.com/codesearch#search/exact_package=chromiumq=WRONG_DOCUMENT_ERR%20file:(%5C.h%7C%5C.cpp)$type=cs Interesting. Maybe that means the exception should be marked historical in the spec: http://www.w3.org/Bugs/Public/show_bug.cgi?id=14576
Re: [whatwg] Feedback on UndoManager spec
On Thu, Oct 27, 2011 at 11:28 AM, Ojan Vafai o...@chromium.org wrote:
On Thu, Oct 27, 2011 at 10:48 AM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa rn...@webkit.org wrote:
The same is true for having apply and reapply. Jonas wanted to get rid
of
reapply altogether and just have
void apply(in boolean isReapply)
In this world, you could do
{ apply: function(isReapply) { return isReapply ? this.doApply() :
this.doReapply(); } }.
I didn't want this API because I'd expect apply and reapply to be
substantially different.
I think either one of those two APIs would be fine. I don't think the
compromise is good, because it gives authors two ways to do the same
thing, which is confusing. I don't know which API is better without
knowing the use-cases for manual transactions. But Jonas' version is
more flexible, because if the two are substantially different you can
always just do
{ apply: function(isReapply) {
if (isReapply) {
// reapply logic
} else {
// totally separate apply logic
}
}, . . . }
which is really no harder to write than
{ apply: function() {
// apply logic
}, reapply: function() {
// totally separate reapply logic
}, . . . }
It's only one or two lines longer, and one level of indent greater.
So I don't think a separate reapply member of the dictionary is
useful. It just makes things more complicated, even if most of the
time the logic will be totally separate.
I disagree. I think the boolean makes things more complicated. Boolean
arguments stink. Every time you want to use this API you need to go look up
the documentation to remember whether the boolean is isReapply or
isApply. There's no such confusion if you have a separate method.
Why is it harder to remember one function name and one attribute name,
than to remember to function names?
/ Jonas
Re: [whatwg] Feedback on UndoManager spec
On Thu, Oct 27, 2011 at 3:10 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Oct 27, 2011 at 11:28 AM, Ojan Vafai o...@chromium.org wrote:
On Thu, Oct 27, 2011 at 10:48 AM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa rn...@webkit.org wrote:
The same is true for having apply and reapply. Jonas wanted to get rid
of
reapply altogether and just have
void apply(in boolean isReapply)
In this world, you could do
{ apply: function(isReapply) { return isReapply ? this.doApply() :
this.doReapply(); } }.
I didn't want this API because I'd expect apply and reapply to be
substantially different.
I think either one of those two APIs would be fine. I don't think the
compromise is good, because it gives authors two ways to do the same
thing, which is confusing. I don't know which API is better without
knowing the use-cases for manual transactions. But Jonas' version is
more flexible, because if the two are substantially different you can
always just do
{ apply: function(isReapply) {
if (isReapply) {
// reapply logic
} else {
// totally separate apply logic
}
}, . . . }
which is really no harder to write than
{ apply: function() {
// apply logic
}, reapply: function() {
// totally separate reapply logic
}, . . . }
It's only one or two lines longer, and one level of indent greater.
So I don't think a separate reapply member of the dictionary is
useful. It just makes things more complicated, even if most of the
time the logic will be totally separate.
I disagree. I think the boolean makes things more complicated. Boolean
arguments stink. Every time you want to use this API you need to go look
up
the documentation to remember whether the boolean is isReapply or
isApply. There's no such confusion if you have a separate method.
Why is it harder to remember one function name and one attribute name,
than to remember to function names?
If I write the following code, it executes, but does the opposite of what I
think it's doing:
{ apply: function(isApply) { //some logic using isApply; } }
With apply/reapply functions, the reapply method wouldn't execute at all.
That seems easier to diagnose to me.
This isn't as bad as cases like addEventListener where the boolean passed in
isn't required to be named, but it still just seems worse to me to have a
boolean argument. Maybe this is just a personal preference. This is
certainly deep in bikeshed territory. I don't much care about this one
instance, but I wouldn't be a fan of littering the web platform with boolean
arguments.
[whatwg] When a script element's child nodes are changed
§4.3.1 The Script Element says: When a |script http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#the-script-element| element that is not marked as being parser-inserted http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#parser-inserted experiences one of the events listed in the following list, the user agent must synchronously prepare http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#prepare-a-script the |script http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#the-script-element| element: * The |script http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#the-script-element| element gets inserted into a document http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#insert-an-element-into-a-document. * The |script http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#the-script-element| element is in a |Document| http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#in-a-document and its child nodes are changed. * The |script http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#the-script-element| element is in a |Document| http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#in-a-document and has a |src http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#attr-script-src| attribute set where previously the element had no such attribute. Bullet point 2 seems ambiguous to me. Does it mean only that the list of children changes, or does it mean that any change to any child node also causes the script to be prepared? In particular, if a script with no src attribute whose only child is an empty text node is inserted into the document, the prepare() algorithm will abort before the already_started flag is set. Later, if I do script.firstChild.insertData(jscode) does that trigger script execution? I haven't tried it out yet to see what browsers do, but I think that the spec should be clarified to make it explicit. David
Re: [whatwg] Feedback on UndoManager spec
On Thu, Oct 27, 2011 at 10:48 AM, Aryeh Gregor a...@aryeh.name wrote: On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa rn...@webkit.org wrote: I meant properties authors added to nodes. e.g. span.myProperty = true; Should span be removed by some automatic transaction, authors may expect it to be restored on undo. That sounds like the ideal behavior, unless it's too difficult to implement. If authors just used Node.dataset, that would solve their problem, but it would be better to behave as expected to start with. Since Gecko and WebKit can both implement this, I'd expect other UAs to do the same. I'll update the spec accordingly. The assumption is transaction works like a regular object unless otherwise stated. I guess I can cite your example though. Some APIs copy objects in some way instead of maintaining a reference. For instance, in WebKit, Selection.getRangeAt() doesn't return the same object you added with Selection.addRange() (although the spec currently says it should). It seems best to be explicit. In the revised spec, I'd say it'll be an entry in the undo transaction history so the wording there should make clear that they're identical objects. But this doesn't define what happens in the face of manual transactions. Also, it's not precise even if there are no manual transactions. UAs don't do anything for manual transactions. They just call unapply/reapply. I mean, if there's a mix of automatic and manual transactions, and the manual transactions don't restore the exact same DOM, nothing says how the UA should unapply/reapply the automatic transactions. It just says the user agent still must do its best effort to restore the DOM state. Right. If authors decide to mess with DOM state of the highest node affected by an automatic transaction, user agents can't do anything to fix that. What's the use-case for manual transactions anyway? I'm sure it's been discussed, but your spec doesn't say. It could use an example. To be able to mix automatic transactions and manual transactions. Consider an application that lets you edit both text and drawing on canvas. Such an app may implement drawing action on canvas as a manual transaction while adding some extra editing commands as automatic transactions and manage them all in the same undo manager. This is well defined in terms of DOM state. The spec says UAs should restore the DOM state so it all depends on how DOM state is defined. I also vaguely remember Ehsan telling me Gecko might have a trouble restoring the exactly same object on undo/redo because of the way its undo and redo are implemented. Well, at some point we want to make sure we have interop if possible, unless it's really performance-critical that this be UA-dependent. IMO, it's critical that this part is left implementation dependent. - Ryosuke
Re: [whatwg] Feedback on UndoManager spec
On Wed, Oct 26, 2011 at 9:42 AM, Aryeh Gregor a...@aryeh.name wrote: 9) In section 3.1 Mutations of DOM, you define DOM changes and DOM State by reference to DOM 3. It would be better if you gave explicit lists, for clarity. I think the only things that qualify as DOM changes to a node are * Changing the data of a text/comment/PI node * Changing an attribute's name or value, for an element * Adding or removing an attribute, for an element * Inserting or removing a child * Any DOM change to a child On my second thought, I'd rather not duplicate information already present on the DOM level 3 spec. Authors, implementors, and developers have spent a lot of time solidifying DOM level 3, and I'd rather defer the definition of what it means to mutuate DOM there. 13) The highest node affecting an automatic transaction is the editing host of the lowest common ancestor of nodes, inside the undo scope associated with the UndoManager to which the transaction is added, mutated while applying the transaction. For editing host of, you might want to link to my definition: http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#editing-host-of In particular, your current text isn't totally clear about what happens if you have non-editable elements nested inside editable ones. If a transaction mutates bar in div contenteditablefoospan contenteditable=falsebar/spanbaz/div, is the highest node the div, or the text node bar? I assume you mean the latter. It seems like just referring to your spec solves the problem because the editing host is null if a node is not editable, in which case, we'll default to the the lowest common ancestor of nodes. - Ryosuke
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
Hi all, I've updated the document: http://rniwa.com/editing/undomanager.html per discussions. Summary of changes: - transaction is renamed to DOM transaction - The value of isAutomatic is read immediately before the transaction is applied - Swapped the definition of clearUndo and clearRedo in the non-normative section to match the rest of the spec - transact() no longer attempts to merge transactions when there are no transactions to merge with - Incorporated Aryeh's feedback - DOM state now include IDL properties and their values Best, Ryosuke Niwa Software Engineer Google Inc.
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Thu, Oct 27, 2011 at 4:23 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, I've updated the document: http://rniwa.com/editing/undomanager.html per discussions. Summary of changes: transaction is renamed to DOM transaction The value of isAutomatic is read immediately before the transaction is applied Swapped the definition of clearUndo and clearRedo in the non-normative section to match the rest of the spec transact() no longer attempts to merge transactions when there are no transactions to merge with Incorporated Aryeh's feedback DOM state now include IDL properties and their values Wait, the last bullet point doesn't mean that changes to IDL properties are in general rolled back, does it? That would be extremely hard to implement in general. It also creates all sorts of weird behavior. Would you for example want to reset HTMLMediaElement.currentTime? And if you set Element.innerHTML back to the value it used to be, it will create all node Nodes. We should just pay attention to changes to Node values, childlists, attribute maps and possibly a few other things. / Jonas
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Thu, Oct 27, 2011 at 6:22 PM, Jonas Sicking jo...@sicking.cc wrote: Wait, the last bullet point doesn't mean that changes to IDL properties are in general rolled back, does it? That would be extremely hard to implement in general. It also creates all sorts of weird behavior. Would you for example want to reset HTMLMediaElement.currentTime? And if you set Element.innerHTML back to the value it used to be, it will create all node Nodes. Definitely not. I'm more than happy to rephrase it if you have a better way of describing it. - Ryosuke
