[whatwg] Feedback on UndoManager spec
Things I noticed while reading through it, leaving aside editorial
nitpicks that wouldn't improve clarity:
1) I was confused at first by the fact that undo goes backward in the
history, and redo goes forward. I would have expected that new
transactions are added to the end of the list, not the beginning.
This way the list goes forward in time instead of backward. Is there
some specific reason for why it's the other way around? E.g., does
this match other platforms' undo APIs? If you keep it this way,
should you change the section title Undo: moving back in the undo
transaction history to Undo: moving forward in the undo transaction
history, and similarly for Redo: moving forward in the undo
transaction history?
2) What happens if you have an Element with the undoscope attribute
that doesn't descend from a Document? Does undo management make any
sense in that case, or should the undoscope attribute have no effect
for detached elements?
3) It looks like there's no mention of the UA clearing old undo
entries. If the UA is expected to remove old undo entries when the
undo history gets too long, this should be mentioned somewhere.
4) In the transact() method, step 2 is Clear all transactions or
transaction groups between before the current undo position. Should
between be removed?
5) You use step numbers in some places, like go to step 8. This is
risky, because if you add or remove a step from the algorithm you have
to track down all the references and change them manually, and if you
miss any your spec is incorrect. Ian avoids this by using named
labels, and saying go to the step in this algorithm labeled 'foo'.
I avoid it by not using gotos at all and using if/while/etc. instead,
although this results in a lot of sublist indentation sometimes.
6) In the definition of redo(), you say (position is incremented by
1). I'm pretty sure you mean decremented.
7) Where you say The item(n) method must return the nth transaction's
associated data, associated data is a link to
#transaction-associated-data, but there's nothing with that id, and
the term associated data doesn't occur elsewhere. Maybe you should
use a tool like anolis to write your spec, so that it will make sure
links like this are correct. If you maintain these links manually,
probably there are other similar errors.
8) I'm confused by what role transaction groups play in UndoManager.
The prose says that an UndoManager has a list of transactions and
transaction groups, but item() only returns transactions. What
happens if the nth item is a transaction group rather than a
transaction? Does item(n) return an array instead of a Transaction?
Similarly, the non-normative description of undo() says the
transaction or all transactions in the transaction group, but the
normative definition says just the transaction and doesn't mention
transaction groups.
Would it make more sense to say that UndoManager has a list of
transaction groups, and that some of the groups might just contain one
transaction, instead of having the list be a mix of transactions and
transaction groups?
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
And the DOM state of a node is its list of attributes (for elements),
its data (for text/comment/PI), and its list of children including all
their DOM state.
10) It's maybe not a big deal, but I think that you want to define
Transaction as a dictionary, not an interface, and remove the
[NoInterfaceObject]:
http://dev.w3.org/2006/webapi/WebIDL/#dfn-dictionary
If I understand correctly, this is what allows you to do transact()
with an object literal as its first argument. If it were an
interface, you'd only be able to get Transaction objects by invoking
some method or attribute that returns them. The difference doesn't
make a lot of sense in JavaScript, admittedly, and I might be
misunderstanding.
11) Any changes made to the value of the isAutomatic attribute after
the transaction had been applied should not change the type of the
transaction. What about changing other things about it? If I do
var transaction = { label: x, apply: foo, unapply: bar, reapply:
baz, isAutomatic: false };
document.undoManager.transact(transaction);
transaction.unapply = quz;
document.undoManager.undo();
which function is called, bar or quz?
12) Relatedly, does item() return references to Transactions, or copies?
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
Re: [whatwg] Feedback on UndoManager spec
Thanks for a great feedback! On Wed, Oct 26, 2011 at 9:42 AM, Aryeh Gregor a...@aryeh.name wrote: 1) I was confused at first by the fact that undo goes backward in the history, and redo goes forward. I would have expected that new transactions are added to the end of the list, not the beginning. This way the list goes forward in time instead of backward. Is there some specific reason for why it's the other way around? This is so that the last transaction is always at position 0, and applying a new transaction does not move the position. The position is non-zero only if we have not applied any new transactions and have done undo. E.g., does this match other platforms' undo APIs? If you keep it this way, should you change the section title Undo: moving back in the undo transaction history to Undo: moving forward in the undo transaction history, and similarly for Redo: moving forward in the undo transaction history? I can change that. 2) What happens if you have an Element with the undoscope attribute that doesn't descend from a Document? Does undo management make any sense in that case, or should the undoscope attribute have no effect for detached elements? This is a debatable point. On one hand, allowing a node with undoManager to be moved to another location in DOM seems nice but on the other hand, being able to move a node with undoManager to a different document will be problematic. And semantically, moving undoManager makes very little sense. 3) It looks like there's no mention of the UA clearing old undo entries. If the UA is expected to remove old undo entries when the undo history gets too long, this should be mentioned somewhere. Yeah, I haven't put much thought into that. I'm thinking that we might need to notify the content (e.g by firing some events) when UAs clear entries in the undo transaction history. 4) In the transact() method, step 2 is Clear all transactions or transaction groups between before the current undo position. Should between be removed? Yes. The revised version is in its way. 6) In the definition of redo(), you say (position is incremented by 1). I'm pretty sure you mean decremented. Yes, I have a revised version which is going to be pushed soon. 7) Where you say The item(n) method must return the nth transaction's associated data, associated data is a link to #transaction-associated-data, but there's nothing with that id, and the term associated data doesn't occur elsewhere. That sentence is very out-of-date. Will update. FWIW, I do use anolis but I've been ignoring all errors for some legacy reason. 8) I'm confused by what role transaction groups play in UndoManager. The prose says that an UndoManager has a list of transactions and transaction groups, but item() only returns transactions. What happens if the nth item is a transaction group rather than a transaction? Does item(n) return an array instead of a Transaction? It'll be an array. I should probably revise that part. Similarly, the non-normative description of undo() says the transaction or all transactions in the transaction group, but the normative definition says just the transaction and doesn't mention transaction groups. Will revise. Would it make more sense to say that UndoManager has a list of transaction groups, and that some of the groups might just contain one transaction, instead of having the list be a mix of transactions and transaction groups? That might be a good idea actually. 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 Also, removing or adding document node, DOCTYPE node, etc... And the DOM state of a node is its list of attributes (for elements), its data (for text/comment/PI), and its list of children including all their DOM state. I'm thinking whether DOM state should also include properties on the node or not. 10) It's maybe not a big deal, but I think that you want to define Transaction as a dictionary, not an interface, and remove the [NoInterfaceObject]: http://dev.w3.org/2006/webapi/WebIDL/#dfn-dictionary If I understand correctly, this is what allows you to do transact() with an object literal as its first argument. If it were an interface, you'd only be able to get Transaction objects by invoking some method or attribute that returns them. The difference doesn't make a lot of sense in JavaScript, admittedly, and I might be misunderstanding. Any object can implement Transaction interface. 11) Any changes made to the value of the isAutomatic attribute after the transaction had been applied should not
Re: [whatwg] Feedback on UndoManager spec
On Wed, Oct 26, 2011 at 1:13 PM, Ryosuke Niwa rn...@webkit.org wrote:
This is so that the last transaction is always at position 0, and applying a
new transaction does not move the position. The position is non-zero only if
we have not applied any new transactions and have done undo.
Makes sense.
2) What happens if you have an Element with the undoscope attribute
that doesn't descend from a Document? Does undo management make any
sense in that case, or should the undoscope attribute have no effect
for detached elements?
This is a debatable point. On one hand, allowing a node with undoManager to
be moved to another location in DOM seems nice but on the other hand, being
able to move a node with undoManager to a different document will be
problematic. And semantically, moving undoManager makes very little sense.
Well, if you do
var span = document.createElement(span);
span.undoScope = true;
what is the value of span.undoManager? Per the current spec, it
should return an UndoManager that works just fine. Is this desired,
or do you want to return null in this case?
Yeah, I haven't put much thought into that. I'm thinking that we might need
to notify the content (e.g by firing some events) when UAs clear entries in
the undo transaction history.
Makes sense.
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
Also, removing or adding document node, DOCTYPE node, etc...
I don't understand what you mean here. How can a Document node be
added or removed, since it can't be the child of anything? If you add
or remove a doctype node, it should be a DOM change to the parent
Document because a child is added or removed, which is included in
what I said.
I'm thinking whether DOM state should also include properties on the node or
not.
You mean IDL properties? We can't include all of those in DOM state.
For instance, it would be extremely unexpected if undo were to undo
changes to document.cookie. Or did you just mean custom IDL
properties that the author added via script, not built-in IDL
properties?
Any object can implement Transaction interface.
I don't think that's how WebIDL works, but I'm not an expert in it.
11) Any changes made to the value of the isAutomatic attribute after
the transaction had been applied should not change the type of the
transaction. What about changing other things about it? If I do
var transaction = { label: x, apply: foo, unapply: bar, reapply:
baz, isAutomatic: false };
document.undoManager.transact(transaction);
transaction.unapply = quz;
document.undoManager.undo();
which function is called, bar or quz?
quz.
This should be spelled out explicitly, IMO.
12) Relatedly, does item() return references to Transactions, or copies?
It returns the original object passed to transact.
This should be spelled out explicitly, IMO.
No. I did not specify that because the only requirement is that UAs restore
DOM states.
I specifically avoided to give any guarantee or implication as to in what
order things are restored
to allow optimizations.
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. If a node is removed from the DOM and undoing restores
it, does it restore the same object or a copy? If a copy, does it
include custom properties that the author added or not? I suspect
you'll say that this is deliberately undefined for the sake of
performance, but it's a potential interop issue.
15) Is the isReapply parameter to apply() needed? The only place I
see where it's used is if the author specifies a manual transaction
but leaves off a reapply() method. In that case, why not just call
apply() with no extra parameter? If the author wanted to have apply()
and reapply() behave differently, they could have specified a separate
reapply() method.
There are good arguments made by Jonas on this topic.
Please look at whatwg archives on this topic.
I looked at the archives and didn't see any good arguments. As far as
I can tell, if authors wanted behavior like with the isReapply
parameter, they could easily emulate it by changing
{ apply: f }
to
{ apply: function() { f(true) }, reapply: function() { f(false) } }
so the extra isReapply parameter doesn't give any extra control to
authors. It just adds a second way to do the same thing, and
complicates the API. It would be simpler and easier to understand if
authors just had to write the extra line or two of code and specify
separate functions for apply/reapply always, instead of being able to
Re: [whatwg] UndoManager: restoring selection after undoing deletion
On Thu, Oct 20, 2011 at 3:16 AM, Ryosuke Niwa rn...@webkit.org wrote: 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 think I'm missing something: why isn't it desirable?
Re: [whatwg] Feedback on UndoManager spec
On Wed, Oct 26, 2011 at 10:57 AM, Aryeh Gregor a...@aryeh.name wrote:
2) What happens if you have an Element with the undoscope attribute
that doesn't descend from a Document? Does undo management make any
sense in that case, or should the undoscope attribute have no effect
for detached elements?
This is a debatable point. On one hand, allowing a node with undoManager
to
be moved to another location in DOM seems nice but on the other hand,
being
able to move a node with undoManager to a different document will be
problematic. And semantically, moving undoManager makes very little
sense.
Well, if you do
var span = document.createElement(span);
span.undoScope = true;
what is the value of span.undoManager? Per the current spec, it
should return an UndoManager that works just fine. Is this desired,
or do you want to return null in this case?
I'm not sure if we should allow that or not. I'm inclined towards not
allowing it for the sake of disallowing undoManager on a detached node.
I'm thinking whether DOM state should also include properties on the node
or
not.
You mean IDL properties? We can't include all of those in DOM state.
For instance, it would be extremely unexpected if undo were to undo
changes to document.cookie. Or did you just mean custom IDL
properties that the author added via script, not built-in IDL
properties?
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.
11) Any changes made to the value of the isAutomatic attribute after
the transaction had been applied should not change the type of the
transaction. What about changing other things about it? If I do
var transaction = { label: x, apply: foo, unapply: bar, reapply:
baz, isAutomatic: false };
document.undoManager.transact(transaction);
transaction.unapply = quz;
document.undoManager.undo();
which function is called, bar or quz?
quz.
This should be spelled out explicitly, IMO.
The assumption is transaction works like a regular object unless otherwise
stated. I guess I can cite your example though.
No. I did not specify that because the only requirement is that UAs
restore
DOM states.
I specifically avoided to give any guarantee or implication as to in what
order things are restored
to allow optimizations.
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.
If a node is removed from the DOM and undoing restores
it, does it restore the same object or a copy? If a copy, does it
include custom properties that the author added or not? I suspect
you'll say that this is deliberately undefined for the sake of
performance, but it's a potential interop issue.
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.
15) Is the isReapply parameter to apply() needed? The only place I
see where it's used is if the author specifies a manual transaction
but leaves off a reapply() method. In that case, why not just call
apply() with no extra parameter? If the author wanted to have apply()
and reapply() behave differently, they could have specified a separate
reapply() method.
There are good arguments made by Jonas on this topic.
Please look at whatwg archives on this topic.
I looked at the archives and didn't see any good arguments. As far as
I can tell, if authors wanted behavior like with the isReapply
parameter, they could easily emulate it by changing
{ apply: f }
to
{ apply: function() { f(true) }, reapply: function() { f(false) } }
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.
- Ryosuke
[whatwg] New attributes would degrade better than new elements
New elements like nav and footer have the problem that some existing user agents don't recognize them, even for the purposes of styling. So if you want to use nav, then - unless you're using it for purely semantic reasons with no idea of styling - you need to use some special trick to make old browsers recognize it or assign your styles to some logically redundant div markup that you use in addition to nav. Therefore, it would be much simpler, for compatibility with existing user agents, to use just div type=nav and div type=footer. Such elements can be styled at will, and if any browsers or search engines wish to recognize semantic markup, type=nav should not be a bigger problem than nav, rather smaller. I understand that this should have been suggested years ago. But I didn't think of the issue, and it seems that neither did anyone else, aloud. And it's not too late, is it? Nobody needs new elements with no required functionality, really. The idea of more compact markup is pointless. People don't read or write markup that much, and if they do, div type=nav is no less semantic than nav. But the latter has the serious drawback of being ignored by many relevant user agents. It does not need to be the 'type' attribute of course. That attribute name is seriously overloaded, so 'kind' might be better. The important thing is to introduce an attribute different from 'class', which currently lets authors use a free naming space. We don't want to interfere with style sheets that might use this or that 'class' attribute value; instead, a new attribute name (defined as semantic, not presentational, but still useful for styling) is called for - rather than new element names, which are born homeless. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] New attributes would degrade better than new elements
Jukka K. Korpela jkorp...@cs.tut.fi schrieb am Wed, 26 Oct 2011 22:38:06 +0300: New elements like nav and footer have the problem that some existing user agents don't recognize them, even for the purposes of styling. So if you want to use nav, then - unless you're using it for purely semantic reasons with no idea of styling - you need to use some special trick to make old browsers recognize it or assign your styles to some logically redundant div markup that you use in addition to nav. Therefore, it would be much simpler, for compatibility with existing user agents, to use just div type=nav and div type=footer. Such elements can be styled at will, and if any browsers or search engines wish to recognize semantic markup, type=nav should not be a bigger problem than nav, rather smaller. I understand that this should have been suggested years ago. But I didn't think of the issue, and it seems that neither did anyone else, aloud. And it's not too late, is it? I'd argue it is: http://caniuse.com/html5semantic -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] UndoManager: restoring selection after undoing deletion
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. This confuses me. I think that WebKit's behavior doesn't make a lot of sense (at least in every case). For example, when Ctrl+Backspacing after a word. But moreover, why is this relevant to the question of whether/how we should restore a selection after undoing an operation? Ehsan
Re: [whatwg] UndoManager: restoring selection after undoing deletion
On Wed, Oct 26, 2011 at 1:03 PM, Ehsan Akhgari eh...@mozilla.com wrote: 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. This confuses me. I think that WebKit's behavior doesn't make a lot of sense (at least in every case). For example, when Ctrl+Backspacing after a word. But moreover, why is this relevant to the question of whether/how we should restore a selection after undoing an operation? WebKit's trying to match Mac's NSTextView here. This is relevant because unapplying / reapplying an automatic transaction should behave like unapplying / reapplying native editing actions. - Ryosuke
Re: [whatwg] New attributes would degrade better than new elements
(11/10/27 3:38), Jukka K. Korpela wrote: Nobody needs new elements with no required functionality, really. The idea of more compact markup is pointless. Every time I ask myself what the use cases of the semantic elements are, my only answer is it makes existing markup shorter. What else use cases do they serve? (This is a serious question since I truly don't know.) (11/10/27 3:38), Jukka K. Korpela wrote: People don't read or write markup that much, I doubt it.
Re: [whatwg] New attributes would degrade better than new elements
On Wed, Oct 26, 2011 at 12:38 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: New elements like nav and footer have the problem that some existing user agents don't recognize them, even for the purposes of styling. So if you want to use nav, then - unless you're using it for purely semantic reasons with no idea of styling - you need to use some special trick to make old browsers recognize it or assign your styles to some logically redundant div markup that you use in addition to nav. Therefore, it would be much simpler, for compatibility with existing user agents, to use just div type=nav and div type=footer. Such elements can be styled at will, and if any browsers or search engines wish to recognize semantic markup, type=nav should not be a bigger problem than nav, rather smaller. I understand that this should have been suggested years ago. But I didn't think of the issue, and it seems that neither did anyone else, aloud. And it's not too late, is it? Nobody needs new elements with no required functionality, really. The idea of more compact markup is pointless. People don't read or write markup that much, and if they do, div type=nav is no less semantic than nav. But the latter has the serious drawback of being ignored by many relevant user agents. It does not need to be the 'type' attribute of course. That attribute name is seriously overloaded, so 'kind' might be better. The important thing is to introduce an attribute different from 'class', which currently lets authors use a free naming space. We don't want to interfere with style sheets that might use this or that 'class' attribute value; instead, a new attribute name (defined as semantic, not presentational, but still useful for styling) is called for - rather than new element names, which are born homeless. Believe me, these discussions were had in the past. All major UAs except old IE handle unknown elements in a way that's acceptable for nav and friends. They have the absolute default styling (such as display:inline), but that's fine, as you can still target them and restyle them. In old IE the new elements are instead parsed as two void elements named nav and /nav, but the IE shiv has been around for years now that fixes that with a one-liner in JS. Once you run that, you're in the same situation as other major browsers. So, it's not a big deal. (Plus, modern browsers *do* recognize the new elements natively now.) ~TJ
Re: [whatwg] UndoManager: restoring selection after undoing deletion
On Wed, Oct 26, 2011 at 4:03 PM, Ehsan Akhgari eh...@mozilla.com wrote: 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. This confuses me. I think that WebKit's behavior doesn't make a lot of sense (at least in every case). For example, when Ctrl+Backspacing after a word. But moreover, why is this relevant to the question of whether/how we should restore a selection after undoing an operation? I was assuming that Ryosuke meant that the word world was selected, and the user hit delete, then undo. So it was selected before the delete, and undoing should re-select it.
Re: [whatwg] UndoManager: restoring selection after undoing deletion
On Wed, Oct 26, 2011 at 4:21 PM, Aryeh Gregor a...@aryeh.name wrote: I was assuming that Ryosuke meant that the word world was selected, and the user hit delete, then undo. So it was selected before the delete, and undoing should re-select it. No text is selected, the user hits control-backspace, and then undo. The restored word world now may or may not be selected, depending on the UA and platform. -- Glenn Maynard
Re: [whatwg] New attributes would degrade better than new elements
On Thu, 2011-10-27 at 04:14 +0800, Kang-Hao (Kenny) Lu wrote: (11/10/27 3:38), Jukka K. Korpela wrote: Nobody needs new elements with no required functionality, really. The idea of more compact markup is pointless. Every time I ask myself what the use cases of the semantic elements are, my only answer is it makes existing markup shorter. Think about what semantic means. In this context, it's about the meaning of the tag to give a context to its contents. A user agent (not the same thing as a browser) doesn't know what div id=nav is, but the modern ones do know what nav is, and what it means. You might not be able to see the use case, but trust me, plenty of other people do, including those behind things like search engines. What else use cases do they serve? (This is a serious question since I truly don't know.) (11/10/27 3:38), Jukka K. Korpela wrote: People don't read or write markup that much, I doubt it. The reason for the new semantic tags is because of an effort to look at what were common elements of pre-HTML5 pages and try to identify parts of a web page that were most common. This led to things like header, footer, nav, section and article being created and adopted by the modern browsers and user agents. If we didn't have them, we'd be back to using divs everywhere, with a mixed assortment of classes and id's used to style them, and to hell with any search engines that tried to understand our web pages. For the same reason that it's better to mark up our text with strong than b it's also better to mark up our pages using the new tags as they give a meaning to areas of our pages that we want. If you don't care about search engines or blind visitors, then don't bother using them. -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] UndoManager: restoring selection after undoing deletion
On Wed, Oct 26, 2011 at 4:25 PM, Glenn Maynard gl...@zewt.org wrote: No text is selected, the user hits control-backspace, and then undo. The restored word world now may or may not be selected, depending on the UA and platform. Ah, okay. Got it.
Re: [whatwg] New attributes would degrade better than new elements
26.10.2011 23:16, Tab Atkins Jr. wrote: Believe me, these discussions were had in the past. I do, but did you draw the conclusions? All major UAs except old IE handle unknown elements in a way that's acceptable That means all browsers except that the most common one. Is that a realistic view? What do you expect to gain by adding new elements, as opposite to the smoother addition of new attributes? 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. Under which circumstances would you vote for the latter, and what do you expect to win? I love gambling, but what's the potential gain here? Pleasing someone's idea of semantic markup, as if attributes could not be semantic? -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] New attributes would degrade better than new elements
On Thu, 2011-10-27 at 00:36 +0300, Jukka K. Korpela wrote:
26.10.2011 23:16, Tab Atkins Jr. wrote:
Believe me, these discussions were had in the past.
I do, but did you draw the conclusions?
All major UAs except old IE handle unknown elements in a way that's
acceptable
That means all browsers except that the most common one. Is that a
realistic view?
Yes it is I think. If people are using versions of IE that old, then
they deserve to have an older version of the web given to them. There
are plenty of browsers available for even the older operating systems
(Chrome, Opera, Firefox) so not having a new one available is no excuse.
What do you expect to gain by adding new elements, as opposite to the
smoother addition of new attributes?
Why is adding attributes smoother? User agents still have to be modified
to 'understand' an attribute to make the same semantic sense as a new
tag, so you gain nothing. You're just swapping one flavour for another.
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.
If you're using an older version of IE then likely it's because you
don't know any different, and also likely that you don't even know what
Javascript is, let alone know how to disable it. I can't back this up
with facts, just personal experience.
Under which circumstances would you vote for the latter, and what do you
expect to win? I love gambling, but what's the potential gain here?
Pleasing someone's idea of semantic markup, as if attributes could not
be semantic?
Attributes can be semantic, but where do you draw the line? From what
you're saying, all tags in HTML could be reconciled into one and you can
just use attributes to differentiate:
tag type=image src=blah.png
tag type=paratext/tag
tag type=italictext/tag
tag type=css.blue{color:#00f;}/tag
Would you really favour using attributes to determing the meaning of a
tag, or would you rather that HTML just follows its natural course and
attributes be used to supplement a tag from default values?
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
Re: [whatwg] New attributes would degrade better than new elements
27.10.2011 0:57, Ashley Sheridan wrote: If people are using versions of IE that old, then they deserve to have an older version of the web given to them. That's rather elitistic, given the fact that many people have no way of upgrading their IE or switching to your preferred browser, and no need to do that apart from some ideas of HMTL5. Why is adding attributes smoother? Browsers recognize the elements. User agents still have to be modified to 'understand' an attribute to make the same semantic sense as a new tag What semantic sense? Exactly what do modern browsers understand about nav for example? What are they required to understand? Just that there's a styleable element. But with div, that's something we have with all browsers. The difference is between fancy new elements and good old elements with new attributes. If you're using an older version of IE then likely it's because you don't know any different That's rather elitistic, isn't it? If we could discard all bad browsers, the world would be nicer, yes, but then we would not really have any browsers, would we? Attributes can be semantic, but where do you draw the line? In the definition of the attributes. If you can make up a new element like nav, why can't you make up a new attribute like type=nav? Would you really favour using attributes to determing the meaning of a tag, or would you rather that HTML just follows its natural course and attributes be used to supplement a tag from default values? Neither attributes nor tag names mean anything by themselves. They get their meanings from specifications or from browser practices. The question is whether the new semantic tags have any useful impact (what might it be?). Inventing new tags may sound cooler than defining meanings for attributes, but it's just an idle game. Is there _any_ demonstrable use of, say, the semantics of nav? And what's the reason why that could not be achieved in the less disruptive way of assigning a standardized meaning to, say, the type attribute of div? -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] New attributes would degrade better than new elements
On Thu, 2011-10-27 at 02:37 +0300, Jukka K. Korpela wrote: 27.10.2011 0:57, Ashley Sheridan wrote: If people are using versions of IE that old, then they deserve to have an older version of the web given to them. That's rather elitistic, given the fact that many people have no way of upgrading their IE or switching to your preferred browser, and no need to do that apart from some ideas of HMTL5. Yes, but then I have to deal with the pain of old versions of IE every day, so my view is not without cause. Why is adding attributes smoother? Browsers recognize the elements. Browsers also recognise HTML5 elements. Going back to a link that someone posted earlier http://caniuse.com/html5semantic it's clear to see that of the 64 browsers listed (including each unique version number as distinct and grouping both occurances of IE9.0 as 1) then it's clear to see that the browsers *not* supporting HTML5 (of which there are 5) are in the minority with regards to all the browsers out there (at least those tested, which does not include some of the more minor browsers such as Konqueror, Galeon Epiphany on desktops and things like Firefox, Dolphin and Boat for Android, for example) User agents still have to be modified to 'understand' an attribute to make the same semantic sense as a new tag What semantic sense? Exactly what do modern browsers understand about nav for example? What are they required to understand? Just that there's a styleable element. But with div, that's something we have with all browsers. It's not just about browsers don't forget, there are other things out there too that visit websites, such as search engines. Try telling me Google isn't aware of HTML5 in web pages and I'll laugh. The semantic value is there also for things like speech and Braille browsers too, which can use HTML5 to aid navigation, by offering differences in the way that nav elements are presented, and easy navigation between sections and articles. The difference is between fancy new elements and good old elements with new attributes. If you're using an older version of IE then likely it's because you don't know any different That's rather elitistic, isn't it? Not really, it's what I've observed to be true. I'm not saying that if you're using an old version of IE that you *must* not know about any different browsers, but that it's more likely that you don't. If we could discard all bad browsers, the world would be nicer, yes, but then we would not really have any browsers, would we? Attributes can be semantic, but where do you draw the line? In the definition of the attributes. If you can make up a new element like nav, why can't you make up a new attribute like type=nav? Because that's how HTML works. You don't just add new attributes to things that exist already to create a whole new meaning for something. You advocate using div tags with custom attributes, but they weren't part of the standard until HTML4. Should we have stopped back then and say we don't need new tags, let's just add attributes to the ones we have already? No, new tags were added to the spec because it was felt they were needed. Would you really favour using attributes to determing the meaning of a tag, or would you rather that HTML just follows its natural course and attributes be used to supplement a tag from default values? Neither attributes nor tag names mean anything by themselves. They get their meanings from specifications or from browser practices. The question is whether the new semantic tags have any useful impact (what might it be?). Inventing new tags may sound cooler than defining meanings for attributes, but it's just an idle game. Is there _any_ demonstrable use of, say, the semantics of nav? And what's the reason why that could not be achieved in the less disruptive way of assigning a standardized meaning to, say, the type attribute of div? Because you shouldn't use attributes to determine the meaning of the content. There's only one such example I can think of where an attribute totally changes the meaning of a tag, and there were calls for getting rid of that ambiguity in HTML5. I speak of the a tag of course, and its double nature as both a link and an anchor. All the other HTML tags are specific and described in their behaviour and meaning for the content they contain, and use attributes only to enhance, supplement or subtly alter their basic function. A p tag is always used for paragraphs, an img tag is always used for images, script is always used for script, etc. nav seems like a perfectly logical choice of tag to add to the spec, as it's a rare day you ever see a website without a navigation bar of some sort; it makes sense. -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] New attributes would degrade better than new elements
If the web was only using the first tags such as(I think) pre then the web woul not be where it is today. 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. 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. I believe that the decision makers are not stupid, they are smart enough to know all these technical issues and conflicts with conflicts that may arrise with additions like this one, and I also believe that they have far more knowledge of this subject and everything that will be changed by a new feature(browsers, search engines, speech browsers, and other UA's) 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!)
Re: [whatwg] Feedback on UndoManager spec
On Wed, Oct 26, 2011 at 10:13 AM, Ryosuke Niwa rn...@webkit.org wrote: 2) What happens if you have an Element with the undoscope attribute that doesn't descend from a Document? Does undo management make any sense in that case, or should the undoscope attribute have no effect for detached elements? This is a debatable point. On one hand, allowing a node with undoManager to be moved to another location in DOM seems nice but on the other hand, being able to move a node with undoManager to a different document will be problematic. And semantically, moving undoManager makes very little sense. 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. I agree that moving a undoManager between elements doesn't make much sense semantically though (even though even that would technically be implementable). / Jonas
Re: [whatwg] Feedback on UndoManager spec
On Wed, Oct 26, 2011 at 11:39 AM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Oct 26, 2011 at 10:57 AM, Aryeh Gregor a...@aryeh.name wrote: 2) What happens if you have an Element with the undoscope attribute that doesn't descend from a Document? Does undo management make any sense in that case, or should the undoscope attribute have no effect for detached elements? This is a debatable point. On one hand, allowing a node with undoManager to be moved to another location in DOM seems nice but on the other hand, being able to move a node with undoManager to a different document will be problematic. And semantically, moving undoManager makes very little sense. Well, if you do var span = document.createElement(span); span.undoScope = true; what is the value of span.undoManager? Per the current spec, it should return an UndoManager that works just fine. Is this desired, or do you want to return null in this case? I'm not sure if we should allow that or not. I'm inclined towards not allowing it for the sake of disallowing undoManager on a detached node. I don't see why the undoManager implementation would need to care why the element it's attached to is in the document tree or not all. All it needs to do is to observe modifications to the descendants of the element. 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 think there is a lot of value in allowing a element to be moved around in a document. Even when that element, or a descendant of it, has a undoManager attached. / Jonas
Re: [whatwg] Feedback on UndoManager spec
On Wed, Oct 26, 2011 at 10:57 AM, Aryeh Gregor a...@aryeh.name wrote:
15) Is the isReapply parameter to apply() needed? The only place I
see where it's used is if the author specifies a manual transaction
but leaves off a reapply() method. In that case, why not just call
apply() with no extra parameter? If the author wanted to have apply()
and reapply() behave differently, they could have specified a separate
reapply() method.
There are good arguments made by Jonas on this topic.
Please look at whatwg archives on this topic.
I looked at the archives and didn't see any good arguments. As far as
I can tell, if authors wanted behavior like with the isReapply
parameter, they could easily emulate it by changing
{ apply: f }
to
{ apply: function() { f(true) }, reapply: function() { f(false) } }
so the extra isReapply parameter doesn't give any extra control to
authors. It just adds a second way to do the same thing, and
complicates the API. It would be simpler and easier to understand if
authors just had to write the extra line or two of code and specify
separate functions for apply/reapply always, instead of being able to
specify either two functions or one that takes a boolean parameter to
achieve the same effect.
I think that in most implementations of the apply/reapply functions,
the differences between the functions will be minimal. I.e. most of
the time you'll want to made the same modifications to the document
the second time a action is applied as you did the first time.
By splitting it out into two callbacks we encourage people to
duplicate that code.
I'd much rather see code like:
transact = { apply: function(reapply) {
do lots of DOM modifications;
if (reapply) {
do reapply specific mutations;
}
unapply: ...
} }
/ Jonas
Re: [whatwg] Feedback on UndoManager spec
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. I guess we can just slightly fail in those cases when transactions are attempted to be undone or redone if you'd prefer that. On Wed, Oct 26, 2011 at 8:26 PM, Jonas Sicking jo...@sicking.cc wrote: I don't see why the undoManager implementation would need to care why the element it's attached to is in the document tree or not all. All it needs to do is to observe modifications to the descendants of the element. You're right. I got UndoManager on a detached node, UndoManager on an adopted node, and the active undo manager all mixed up. It's fine to have UndoManager on a detached node since it can never host the active undo manager. 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. I think there is a lot of value in allowing a element to be moved around in a document. Even when that element, or a descendant of it, has a undoManager attached. Agreed. - Ryosuke
