Re: [whatwg] onclose events for MessagePort
On Tue, Oct 1, 2013 at 8:45 PM, Ian Hickson i...@hixie.ch wrote: Crashing is non-conforming. rules-lawyer href=http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#conformance-requirements; Terminating the process with SIGSEGV if a page exceeds an implementation-limit on memory usage seems perfectly conforming to me. /rules-lawyer Whether the case presents real-world difficulties for authors sounds like the more interesting question here.
Re: [whatwg] Submitting contentEditable Content In A Form
On Wed, Dec 19, 2012 at 10:49 PM, Ian Hickson i...@hixie.ch wrote: How common is it for a part of a page to be editable when the page is loaded, for there to be no formatting UI, for the page to not mind if the user uses the browser's own formatting features (e.g. dragging and dropping formatted text into an editable region, using Ctrl+B, etc), and for the process of submitting the update to the server to consist of literally a form submission? I don't recall ever seeing a page like this. Literally every time I've seen contenteditable, it's had _some_ script beyond what is needed to shunt the value into a form control. If it's something that really does happen commonly, then sure, let's support it. In my experience, practically any use of contenteditable involves script of some kind, and in fact it's hard to make any practical use of it with less than hundreds of lines of script. Thousands is more typical. So the few lines required to submit don't seem significant. (Not all browsers make Ctrl-B or such do anything automatically in contenteditable, either, so you can't even get basic richtext formatting without script.)
Re: [whatwg] Submitting contentEditable Content In A Form
On Thu, Oct 18, 2012 at 1:23 AM, Ian Hickson i...@hixie.ch wrote: Incidentally, it seems to use a WebKit-specific plaintext-only value. Should we spec that? Aryeh? It's filed as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14554 If this should involve changes to HTML, let me know. In principle, yes, this should be specced. In practice, it would require extensive changes to the editing spec and a lot of careful thinking, and no one is really working on editing implementations anyway. Gecko's editor code is in maintenance mode, I haven't received a single piece of feedback ever about editing from IE or Opera people, and WebKit is the one that already implements the feature, so I don't see the effort as being worth the time spent right now. (I did receive feedback from Opera about selection, but not editing as far as I remember.) The same goes for any other proposed editing spec features. When I see people actually implementing the existing spec, that's when it will make sense for me to spend more of my time adding more stuff to it. Until then, I might fix bugs, but that's it.
Re: [whatwg] Should editable elements have placeholder attribute?
On Thu, Sep 6, 2012 at 6:30 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Note that this shouldn't be hard to do without magic. Just something
like this in the UA style sheet:
[contenteditable]:empty { min-height: 1em; }
contenteditable is not a boolean attribute -- you'd need to do
[contenteditable=true]. But I don't think that works right if there's
leading or trailing whitespace or similar. In theory, this might do
the trick:
:read-only :read-write { min-height: 1em; }
except that WebKit doesn't let editability affect
:read-only/:read-write, because it uses a CSS property to track
editability. (Gecko uses a per-node boolean flag and just iterates
through ancestors when necessary.)
Also, :empty won't help if there's a child that's only whitespace, like
div contenteditable
/div
or
div contenteditable /div
which would be a case we'd want to handle. But if you omit the
:empty, it would break if there were smaller-than-usual text.
Also, 1em isn't the same as if you put some text in it. Generally,
typing some text is supposed to create a p, which might make it
substantially taller than 1em depending on margin collapsing, right?
You'd know this better than me.
So I don't think this would be so trivial to spec. If you can come up
with something that works, I'm all ears!
On Thu, Sep 6, 2012 at 6:53 PM, Ojan Vafai o...@chromium.org wrote:
While WebKit does put the magic br in, that's not what avoids the
collapsing in this case. If you set the innerHTML to , it still doesn't
collapse. We actually hard-code that editing hosts don't collapse.
I know -- this is the non-standard special case I referred to. :)
This is technically not per spec at present, but I wouldn't object to
standardizing it if it can be done reasonably. The only thing is, I'm
not sure it can be. I'm not convinced that hardcoding editing logic
into CSS is a good idea unless it's needed for web compat, which I
imagine it's not, because Gecko doesn't do it.
But on the other hand, it looks like everyone but Gecko does do it,
although I'm sure the details are totally different. And it's
certainly nice for usability. So it would be nice if we had some good
way to spec it. I wonder if Opera does it in a saner-to-spec way.
Re: [whatwg] Should editable elements have placeholder attribute?
On Sat, Sep 1, 2012 at 4:22 AM, David Young dyo...@pobox.com wrote: This demonstrates some unexpected contenteditable results on Chrome 21.0.1180.82 under Mac OS X. I cannot seem to return the contenteditable to the empty state again---i.e., to the state where the placeholder shows---using Chrome. All that I have entered is a space. Backspacing over the space leaves a br. Inserting a space again deletes the br. In Firefox 3.6.19 it is necessary to insert two spaces before a br appears; the br cannot be deleted, not even by inserting a space. :-) It should never be possible to make a contenteditable element contain nothing, once it has something in it, because then it would collapse to zero height and you wouldn't be able to click on it. (IIRC, some browsers have non-standard special cases for contenteditable elements and make them one line high even if they're empty, but this isn't per spec.) So if nothing else would be left, browsers are supposed to put a br in, which they remove as soon as anything else would stop it from collapsing. WebKit does this pretty much per spec. Gecko doesn't bother removing the br's it's added, which is messier and not per spec. IE uses nbsp;'s instead of br's to stop collapsing, last I checked, except IIRC, they're magical and can vanish depending on whether you look at them with DOM methods vs. innerHTML. All this is relevant to any contenteditable element, incidentally, not just the editing host. If you have px/p and the user backspaces over the x, it's supposed to become pbr/p.
Re: [whatwg] content editing (was Re: Request for new DOM property textarea.selectionText)
On Wed, Sep 5, 2012 at 10:37 PM, David Young dyo...@pobox.com wrote:
I have to say that I'm uneasy with the way that this API wavers between
answering interaction-design questions and telling what ought to happen
to the DOM under, say, an execCommand('insertText'). Just for example,
lots of words are spent on just what to do when the user inserts two or
more consecutive whitespace characters where the white-space property
is 'normal' instead of 'pre-wrap'. That seems like a question to leave
to the interaction designer. Different word processors through the
years have treated consecutive spaces differently, especially in tricky
contexts like the right margin.
See the todo here, at the top:
http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#additional-requirements
Conceivably, some things could be left unstandardized, with each
implementer choosing how to do it based on platform conventions, etc.
However, based on the unpleasant experience that we've had in the past
when editors leave browser behavior undefined, I chose to err on the
side of precisely specifying as much as possible. If I get
implementers coming to me and saying that one specific feature should
be allowed to vary because they want to implement it differently, then
I'll add specific exceptions at that point, ideally as narrow as
possible.
I say that it should be left to the interaction designer because when an
intern and I explored the idea of embedding a word-processor directly
into a web pages using JavaScript/DOM, I remember discovering no fewer
than three different right-margin behaviors in a survey of Apple's
TextEdit application, MS Word, the Canon Cat (an information appliance
from 1987). Then I invented a fourth behavior. There was not an
obstacle to implementing each in the DOM. I'm sure that each behavior
must have its fans and its detractors, but when I demonstrated the
differences in a staff meeting, the behavior of MS Word so defied the
expectations of one MS Word-using engineer that he protested that it
*could not be*.
This suggests that perhaps the behavior of some of those was just a
bug. Anyway, what behavior would you suggest as a possible
alternative? Remember that our hands are tied somewhat here -- we're
restricted to things that can be expressed as one-off DOM mutations.
execCommand() can't persist state other than in the DOM itself.
Also, keep in mind that for web stuff, interop is important in its own
right. TextEdit and Word are different programs and are meant to have
different functionality. But the *same* website shouldn't vary in
behavior just because the user uses a different browser, in general.
We want browsers to be as interchangeable as possible, so users can
easily switch between them. The authors of Word do not highly
prioritize interchangeability with competitors, to put it mildly. :)
So, anyway, I question the wisdom of standardizing such fine points of
the UA behavior as what two taps of the spacebar will do: I believe that
reasonable people can disagree, and setting a standard seems premature.
In the happy event that we have no fewer than two implementers who
look at the spec and want to implement it to the last detail, I will
be delighted to reconsider this point. For the time being, no one is
seriously implementing it at all, so I think it's premature to make
changes based on what implementers might possibly think when they do
get around to implementing it. :)
There do seem to be a couple of areas where web standards seem
to be lacking if you aspire to write a JavaScript/DOM word
processor. One area is keyboard input: we had to use a table of
keycode-letter/function correspondences, (at least) one per browser, to
interpret keypresses consistently. Another area is locating the precise
character position where a mouse click occurred: we found it doable by
binary search, but it was kind of a pain. Locating and decorating the
soft breaks on a page was another pain point.
The editing spec doesn't intend to give you tools to write your own
word processor using DOM APIs. The intent is to write a spec for a
preexisting poorly-designed API that was made up by Microsoft in the
1990s, and subsequently copied inaccurately by other browsers, which
in turn all added their own unspecified extensions and quirks.
I agree that if you were actually trying to write a good editor from
scratch, contenteditable is not what you want at all. And in fact,
most real-world editors use contenteditable as little as possible, and
execCommand() not at all. But we still have to spec it. Browsers
have to support the API for compatibility with existing content,
regardless of how terrible it is as an API.
Re: [whatwg] A mechanism to improve form autofill
On Thu, Aug 2, 2012 at 9:42 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 26 Jul 2012, Smylers wrote: Ian Hickson writes: Also, I do not understand why we have credit cards types. Is anyone willing to have his credit cards information saved locally? Sure, why not? I am too, but I can understand why people who share their computer (and user accounts) with others wouldn't want their card numbers saving. That's a UA configuration issue, presumably. (Similar to saving passwords.) In fact, Chrome already autodetects credit card numbers for autofill (presumably based on a heuristic) and has a special dialog for whether to remember them, similar to the password-remembering dialog. At chrome://chrome/settings/autofill, there are fields for both addresses and credit card numbers. This is documented here: https://support.google.com/chrome/bin/answer.py?hl=enanswer=142893p=settings_autofill IIRC, one option when it asks you to remember credit cards is don't ever remember credit card numbers -- although I'm not sure, since I think I picked it and thus haven't seen the dialog in a long time. :)
Re: [whatwg] A mechanism to improve form autofill
On Tue, Jul 24, 2012 at 2:41 AM, Ian Hickson i...@hixie.ch wrote:
Are there any common fields missing from the list above?
Government-issued ID numbers might be worth adding. In America,
social security numbers are sometimes used for this purpose, but are
treated as semi-secret, so you usually don't enter them on web forms.
(My American college did use my social security number as an ID
number, but not in web forms as far as I remember.) But in Israel,
and I assume some other countries, there are national ID numbers that
are considered public info. E.g., my Israeli id number (mispar zehut)
is 332752187. It's printed on my checks and things like that, so it's
no secret, and since it's guaranteed to exist and be unique, various
institutions use it for login instead of or in addition to a username
-- my bank, health insurance provider, etc.
So it might be useful to remember. I don't know if it's a common
enough need to make it into a first pass, though, since I guess most
countries don't have it. If it is, probably you'd want to have
subtypes for every country's id number, maybe using a country code
suffix.
I would also like to point out that this feature seems to overlap with
not only type= (as has been pointed out), but inputmode= as well,
and for that matter pattern=. I think it would be quite unfortunate
if authors found themselves writing things like
input inputmode=numeric pattern=\d{16} autocompletetype=cc-num
because that's logically pretty redundant. But maybe it's the only
way to preserve our sanity, because it allows authors to figure out
what combination of features they need for their inputs instead of us
trying to figure out in advance what the possibilities are.
Re: [whatwg] A mechanism to improve form autofill
On Thu, Jul 26, 2012 at 11:52 AM, Smylers smyl...@stripey.com wrote:
Perhaps specifying certain autocomplete types could set defaults for
pattern and inputmode? So for this example autocomplete=cc-num would, if
pattern isn't specified, imply pattern=\d{16}, and equivalently for
inputmode?
That would be surprising, because autocomplete is just a hint, while
pattern doesn't allow form submission if it's not met. Also, I
couldn't swear to you that all credit card numbers are actually 16
digits, or that they will forever be 16 digits, so I'm hesitant to
make that connection canonical.
Re: [whatwg] Should editable elements have placeholder attribute?
On Thu, Jun 14, 2012 at 1:11 AM, Ian Hickson i...@hixie.ch wrote: I strongly disagree. input and textarea are high-level constructs, so it's fine for them to be defined by the UA's platform. But contenteditable is a very low-level primitive. We can't just punt on how it interacts with CSS; otherwise people will have no way to reliably make UIs with it. I don't know why you think contenteditable is lower-level than input/textarea. In the end this is the check that I'm using at the moment (I didn't perform extensive tests, just enough to check that it seemed to work) var value = data.replace( /[\n|\t]*/g, '' ).toLowerCase(); if ( !value || value == 'br' || value == 'pnbsp;br/p' || value == 'pbr/p' || value == 'pnbsp;/p' ) return true; Now there's a problem we should fix. Having five different representations of nothing seems like a terrible position for us to be in. If you type some stuff and then delete it all, the desired result will vary based on lots of factors, e.g.: * Whether div or p is being used for paragraph separators. Both pbr/p and divbr/div might make sense for nothing, depending. This is author-configurable using the defaultParagraphSeparator command. * Whether there was any styling present before. If all the text was previously bold, for instance, deleting everything might result in something like pbbr/b/p, because per spec, deletion doesn't remove style tags from empty lines. * Whether there was any other special markup. If something (like execCommand(insertHTML)) made the first line have p id=foo, then deleting everything would result in p id=foobr/p. * What the author specified as the initial contents of the editable area. If you have div contenteditablebr/div to start with, and the user puts the cursor there and then types foo and then deletes it, you'll go back to having just br, because nothing ever inserted a p or div or anything. (As soon as the user hits Enter, both the old and new lines are wrapped in a paragraph separator per spec, although only IE/Opera do this right now.) Really, you can have any HTML markup at all in contenteditable, and we can't avoid that. There's not going to be any reliable way to figure out what nothing is if you can't answer the same question for arbitrary HTML.
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, May 10, 2012 at 10:58 AM, Edward O'Connor eocon...@apple.com wrote: The srcset= attribute takes as its argument a simplified variant of the image-set() microsyntax[2]. It would look something like this: img src=foo-lores.jpg srcset=foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x alt=decent alt text for foo. img srcset takes one or more comma separated image specifiers. An image specifier consists of a URL to an image asset and an associated scale factor, expressed as a number followed by the literal character 'x'. (The value of img src is treated as if it had a 1x scale specified, so you can avoid duplicate references to the base asset.) User Agents may make their asset selection before fetching any of the assets, thus avoiding multiple asset loads the associated performance problems in constrained bandwidth environments. I'd like to throw in another use-case that might be addressable by the same feature: allowing Save As... to save a different version of the image (e.g., higher-res) than is actually displayed. Wikipedia, for instance, often has very high-res images that get scaled down for article viewing to save bandwidth and avoid possibly-ugly rescaling. (At least historically, some browsers used very bad rescaling algorithms.) It would be nice if when users saved the image, they saved the full-res version. Perhaps browsers could save the highest-res image available, rather than the one that happens to be used for display right now. Another obvious use-case I'd like to point out is print. It's not quite as trendy as the iPhone Retina display -- in fact maybe it's getting passé :) -- but print is generally higher-res than display, and it's common for images to appear pixelated when printing. This use-case might have the same requirements as the iPhone Retina display, but it should be kept in mind in case it doesn't. A fourth use-case I'd like to suggest is vector images. Last I checked, many authors don't want to serve SVG directly because too many browsers don't support it in img (or at all). Perhaps it should be possible to specify vector or something in place of a scale factor, to indicate that the image should be suitable for all resolutions. (A possible problem with this: very detailed SVGs can be much larger than the equivalent bitmaps, so the bandwidth tradeoff might not always be good. But authors can worry about that themselves, I guess, and not specify such vector images as possible sources.) It's possible that the best solution won't accommodate all of these use-cases, but I'm just throwing them out here so that they can be taken into account.
Re: [whatwg] img srcset for responsive bitmapped content images
On Thu, May 10, 2012 at 2:44 PM, Edward O'Connor eocon...@apple.com wrote: I'm not sure about this one. If a browser doesn't support SVG, I want to be able to provide a bitmap fallback regardless of how I included the SVG—in both the img src or inline svg element cases. img srcset isn't about providing fallback, so this might best be addressed with a different feature. There's already an easy script-free way to support fallback in inline svg -- add an img inside some element that SVG ignores. (I can't remember which one is recommended, but IIRC there is one that's suitable.) A browser that doesn't support svg will ignore all the SVG tags as unrecognized wrappers, and just display the img. A browser that supports svg will ignore the img. There's no good existing fallback for img that I know of. In practice, any browser that supports srcset will support SVG-in-img, and in principle vector images can be thought of as infinite-res, so it seems like it might be a useful feature to tack on. But this is the weakest use-case given, I agree, and it might be best not to solve it.
Re: [whatwg] Should editable elements have placeholder attribute?
On Wed, May 2, 2012 at 8:00 AM, Ryosuke Niwa rn...@webkit.org wrote: Hi, Would it be useful to have placeholder content attribute on elements that are editable? (i.e. contenteditable=true). According to the original WebKit bug 21286https://bugs.webkit.org/show_bug.cgi?id=21286, this may reduce the amount of code authors have to write. This sounds like a good idea to me.
Re: [whatwg] Should editable elements have placeholder attribute?
On Wed, May 2, 2012 at 9:59 AM, Ryosuke Niwa rn...@webkit.org wrote: Great. I think the tricky part will be defining exactly how and when the placeholder is displayed. e.g. Should it be treated as if there is a text node in the editable element? Should we ignore things like br or collapsible spaces when determining whether the element is empty or not? Currently the spec isn't clear about this for input, so I don't think it needs to specify exactly for textarea or contenteditable either. It can be left as a UI decision. As far as QoI goes, I think you'd want to display it as long as there's no visible text or images or things. pbr/p should still display the placeholder, and probably so should pfont color=redbr/font/p, etc. As long as there's no text (or img, etc.) that's visible to the user -- if it *looks* empty, the placeholder should display. But this should be up to the UA.
Re: [whatwg] Request for new DOM property textarea.selectionText
On Mon, Apr 30, 2012 at 5:35 PM, David Young dyo...@pobox.com wrote: I have seen this spec before. It seems to have something to do with creating a word processor-like environment in the browser, something that I am acutely interested in, but there isn't much introduction/justification to it. Is there an executive summary of the editing API somewhere? I filed a bug to remind me to add a better intro at some point, but no guarantees that I'll get to it in the foreseeable future: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16894 You can read tutorials and such that you can find by Googling contenteditable or execCommand. This page looks especially good, at a glance, like most things written by Mark Pilgrim: http://blog.whatwg.org/the-road-to-html-5-contenteditable On Tue, May 1, 2012 at 1:03 AM, Ojan Vafai o...@chromium.org wrote: This looks good to me. Could we just call the method setText though since the range values are optional. setRangeText, in retrospect, is wordy and confusing in a way that setText isn't IMO. .setText(foo) sounds like it should set the entire text, not just the selected text.
Re: [whatwg] Request for new DOM property textarea.selectionText
On Sun, Apr 29, 2012 at 10:29 AM, Ryosuke Niwa rn...@webkit.org wrote: That sounds like a tangential issue. We can easily extend execCommand to support arbitrary range(s) since such a feature is also valuable in richly editable areas. Ranges don't exist in plaintext areas. How would you get a Range object that selects text in a textarea? That's why we have separate .selectionStart, .selectionEnd, etc. properties to start with. In this case, we have an API, namely document.execCommand, supported by two major browser engines (for years) that provides more or less the same functionality as the proposed API. delete works in IE as well as WebKit. insertText (which is what would be needed for this feature) is WebKit-only, in both plaintext and richtext.
Re: [whatwg] Request for new DOM property textarea.selectionText
On Sun, Apr 29, 2012 at 11:39 PM, David Young dyo...@pobox.com wrote: I'm curious what advantages document.execCommand() has over the customary DOM API for adding/deleting/moving nodes? execCommand() does vastly more complicated things than the DOM APIs. See the spec for details: http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html
Re: [whatwg] Quirks Mode Standard
On Fri, Feb 10, 2012 at 10:37 AM, Boris Zbarsky bzbar...@mit.edu wrote: I agree that having the list for lengths reduces the scope of the problem somewhat. But the color quirk means that any shorthand that includes colors will run into ambiguity issues if any keywords for any subproperty only use letters in the range a-f. I _think_ we can't hit that case now, but going forward that will either place a restriction on keyword values or we'll need to define how to resolve the ambiguity somehow. Even for lengths, if we ever add any new subproperties to border, say, that happen to take numbers we would run into trouble. I'd rather not overconstrain future development of CSS by how we define quirks behavior. Why not just say that these quirks only apply to existing syntaxes, not new ones? I was quite surprised to find that unitless numbers worked for 'transform-origin' in quirks mode.
Re: [whatwg] video element not ready for prime time
On Thu, Jan 12, 2012 at 12:46 PM, Francis Boumphrey boumphre...@gmail.com wrote: e.g. video src='myvideo.mp4' controls and my user agent does not support the format, all I get (in my versions of Opera and Firefox) is a blank screen. No message (as I would get with embed) and as far as I can see there is no way for me as an author to know that the video is not being played so I cannot code a 'write around'. Boris answered the rest of your questions, but here's a way to detect errors: data:text/html,!doctype html video src='nonexistent.mp4' controls onerror='alert(error)'/video If you use source, the error event is fired at the source element instead and doesn't bubble (why not?), so you have to put onerror on the source element instead. I don't know why UAs don't provide their own error messages, though. They provide error icons for failed image loads.
Re: [whatwg] API design restrictions due to barewords in onxxx= attributes
On Fri, Nov 25, 2011 at 11:06 PM, Boris Zbarsky bzbar...@mit.edu wrote: It would break existing pages that use expandos on elements or documents via barewords in on* attributes. Isn't that the point of look at element's named properties (if it has any) and look at element's form's named properties (if it has a form)? I assumed named properties meant expando attributes. We could add a check for the document's named properties too. This way, if we introduce Element.prototype.matches or something, that would be skipped entirely in bareword on* lookups. The only new properties we define that would ever be hit for bareword on* lookups are ones on the window, and those would be last in the lookup chain -- which is the same behavior as for non-on* bareword uses.
Re: [whatwg] WHATWG on Google+
On Mon, Nov 21, 2011 at 11:43 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: However, I don't think this rough classification actually helps me much to identify what I want to look at. If at least the area of change is mentioned in your descriptive text, that would help me much more. For me media (or video) and webvtt are of particular interest. I am particularly annoyed when I read things like Forgot to remove this now false note but don't know which spec area it applies to - if it's in media I will check no matter whether [e] or [c], if it's in - say - tables, I likely won't care. I agree that it would be helpful if commit messages were more informative. For editorial changes, you often don't mention anything that gives a clue about the subject of the commit. E.g.: http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2011/004902.html pedantic nit: spec required a valid value but then required the empty va [...] That commit is apparently relevant to date parsing, but you can't tell without looking at the diff, which is often hard to decipher if there's not enough context. You're generally good about informative commit messages for non-editorial changes, but editorial changes are often interesting too. (Otherwise, why not just remove all the non-normative parts of the spec?)
Re: [whatwg] Feedback on UndoManager spec
On Mon, Nov 7, 2011 at 8:03 PM, Ryosuke Niwa rn...@webkit.org wrote: * The author must not be forced to deal with manually handling DOM state just because they want to handle non-DOM state. I disagree with this requirement. This should be an opt-in feature, not something forced upon authors. I think we agree, then. My point is that authors should still be able to use automatic transactions even if they want undo/redo to affect non-DOM state too, e.g., canvas. Authors should only be forced to use manual transactions if they actually don't want the browser to maintain DOM state. So allowing unapply/reapply on manual transactions would resolve this issue. Calling unapply/reapply methods for automatic transaction seem like a good non-controvertial change. Will make the change in the next iteration. Okay, great. Okay, thanks. This is the key point I was missing. Just so I understand, what's supposed to happen here: 1. Some changes get made in an automatic transaction. 2. Some changes get made in no transaction at all, just a script calling DOM methods. 3. execCommand(undo) It depends. If the DOM changes made in step 2 does not mutates the highest node affecting the automatic transaction in step 1, then step 3 succeeds and UA undoes every DOM change made in step 1. If the DOM changes made in step 2 mutates the highest node affecting the automatic transaction in step 1, then UAs still does its best to unapply the transaction but doesn't need to guarantee the states are restored completely. From my two simple tests, it looks like this is how WebKit behaves, more or less, but not Gecko or Opera. We can't. That's why I have spec'ed the way it is. Keeping the entire DOM state is extremely expensive. Okay. Then I wonder what it is Gecko is doing, though. Yeah, it'll be nice if we could define the behavior precisely but then again, there's nothing that prevents authors from modifying DOM in any arbitrary way. Right, but at least then it will either work in all browsers or break in all browsers. This is very expensive to implement, and I'll be opposed to implementing such a behavior at least in WebKit. Okay. On Mon, Nov 7, 2011 at 11:27 PM, Jonas Sicking jo...@sicking.cc wrote: Yes, we don't want to track all changes ever made, that is indeed expensive. What does Gecko actually do, roughly? In my second test from before, it looks like undo undoes a change to an unrelated part of the DOM, which suggests Gecko is actually tracking all changes to the DOM: data:text/html,!doctype html div contenteditableFoo/div script var div = document.querySelector(div); getSelection().selectAllChildren(div); document.execCommand(bold); document.body.appendChild(document.createTextNode(bar)); document.execCommand(undo); /script bar doesn't appear anywhere in the DOM in Firefox 9.0a2. How does that happen, if it's not tracking all DOM changes to undo them? What changes does it not track? What we should do is to define exactly how the tracking works, and what exact operations the browser does to revert a automatic transaction. That way it doesn't matter (from a consistency point of view) what changes the page does outside of transactions. All browsers will react the same to the unknown state of the DOM. For example, if we say that for each node removed when a automatic transaction is created, the browser records that nodes old parent and previous sibling. Then we can say that when the automatic transaction is undone, the browser checks that the old previous sibling is still a child of the parent (unless the previous sibling was null), if the test passes, the browser inserts the removed node after the previous sibling in the parent. We could also remember both the following and previous sibling in order to be more resilient against unrecorded mutations. There's lots of options here. The point is we should define the exact algorithm that the browser should use. I'm in favor of any solution that produces consistent results across browsers. I think it's a bad idea to leave it unspecified. On Mon, Nov 7, 2011 at 11:54 PM, Ryosuke Niwa rn...@webkit.org wrote: It'll be nice if we could specify that precisely. From what Anne told me today, all DOM operations are defined in terms of http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node-insert and http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node-remove so we can probably define what should happen when unapplying/reapplying either one. There are also attribute changes, and changes to CharacterData data, and changes to JS expando attributes.
Re: [whatwg] Automatic transaction should support changing the value of input/textarea
On Tue, Nov 8, 2011 at 4:48 AM, Jonas Sicking jo...@sicking.cc wrote: Yup, that seems like the right solution. But we should specify exactly what the UA should store. I.e. should it store the whole before/after values? What should it do if the after-value doesn't match the current value when the transaction is reverted? Changes to CharacterData all internally go through the replace data algorithm in DOM4: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-cd-replace I've been told this is more or less how Gecko works internally, too. It's not so obvious what conditions to check for, though. I wrote a test: data:text/html,!doctype html div contenteditableabc/div input type=button value=insert onclick=' var sel = window.getSelection(); sel.focusNode.replaceData(Math.min(sel.focusOffset, sel.anchorOffset), Math.abs(sel.focusOffset - sel.anchorOffset), x) ' Type d at the end, click button, undo: abcd - abcdx - abcx Type d at the end, select d, click button, undo: abcd - abcx - abc Type d at the end, select cd, click button, undo: abcd - abx - abx Type d at the end, move cursor before b, click button, undo: abcd - axbcd - axbd Select b, type d, click button, undo: adc - adxc - abxc Select b, type d, move cursor before d, click button, undo: adc - axdc - abdc Gecko and WebKit agree in all of these cases. It suggests that to undo the replaceData, they just do a reverse replaceData with the same offset/count, without any sanity check on the contents of the text node. In the first four cases, the thing being undone is an insertion of one character at offset 3, so they just delete the character at offset 3 if any. In the last two, the thing being undone is changing character 1 from b to d, so they just change character 1 back to b regardless of what it is. This is simple and workable, although of course a bit weird if the contents have actually changed.
Re: [whatwg] Feedback on UndoManager spec
On Tue, Nov 8, 2011 at 11:55 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Nov 8, 2011 at 6:12 AM, Aryeh Gregor a...@aryeh.name wrote: Yeah, it'll be nice if we could define the behavior precisely but then again, there's nothing that prevents authors from modifying DOM in any arbitrary way. Right, but at least then it will either work in all browsers or break in all browsers. I don't really follow your logic here. If the behavior is not defined precisely, different browsers will behave differently. This means a page might work in one browser, but not in another. So authors will write a page, test, find that it breaks, and work around the problem so that their tests work in all browsers they care about. Then it will still break in other browsers. Or else authors have to fix the page so it works in one browser, then write entirely different fixes for another browser. Having browsers behave differently is always bad. Behavior should be standardized so they behave the same. Even if the behavior is bad and it's not what authors want, authors can always work around it to get what they want, as long as it's the same in all browsers. So the most important thing is all browsers have the same behavior, and the second most important thing is that the behavior is actually desirable. Attributes are easy because it's just a string, and we can always restore that. CharacterData is tricky since I don't want force UAs to store the entire old data. See other thread for my brief investigations on how UAs seem to do this in practice (they don't seem to store the old data, just any deleted parts).
Re: [whatwg] Automatic transaction should support changing the value of input/textarea
Oops, Gmail's new look is confusing me. I did Reply instead of Reply to all. Resending. Ryosuke, you replied off-list, so you should probably repeat the reply on-list. On Tue, Nov 8, 2011 at 11:39 AM, Ryosuke Niwa rn...@webkit.org wrote: The value of input and textarea elements isn't CharacterData. The default value of textarea maybe stored as CharacterData but not the value. Sorry, I was confusing this with the other thread or something. But it would make sense for the same algorithm to apply. E.g., if the user made a change to some text in an input and then a script changed it and then the user tried to undo, the result should be the same as if the same sequence of actions occurred in a contenteditable text node. Test: data:text/html,!doctype html input value=abc input type=button value=insert onclick=' var input = document.querySelector(input); input.value = input.value.substring(0, input.selectionStart) + x + input.value.substring(input.selectionEnd); ' Running the same manual tests as before in WebKit: Type d at the end, click button, undo: abcd - abcdx - abcx Type d at the end, select d, click button, undo: abcd - abcx - abc Type d at the end, select cd, click button, undo: abcd - abx - abx Type d at the end, move cursor before b, click button, undo: abcd - axbcd - axbd Select b, type d, click button, undo: adc - adxc - abxc Select b, type d, move cursor before d, click button, undo: adc - axdc - abdc WebKit behaves exactly the same for CharacterData nodes and inputs, it looks like. Gecko seems to not undo user changes if there were any script changes to the value -- in all six of those tests, undo does nothing, unlike in WebKit. On Tue, Nov 8, 2011 at 11:47 AM, Ryosuke Niwa rn...@webkit.org wrote: Hm... so the only way this could happen is if script assigned a value to the value IDL attribute, so it's probably safe to say we should abort (i.e. no restoration of the value) Do you think that's how modifying contenteditable text nodes should behave too? Also, doesn't this require that you store the old value with every change? The way WebKit seems to do it now for both inputs and text nodes is to just dumbly reverse the operation without checking if it makes sense, which means you only need to store offset, removed text, and length of added text.
Re: [whatwg] Feedback on UndoManager spec
On Tue, Nov 8, 2011 at 12:44 PM, Ryosuke Niwa rn...@webkit.org wrote: I don't think adding noundo solve this problem. I agree, I abandoned that idea a while ago. It only makes sense if undo undoes all DOM changes, even if they're outside a transaction. Otherwise it's pointless. I didn't realize at first that that isn't the way it worked, which is why I suggested it. We seem to be having trouble understanding each other lately.
Re: [whatwg] Feedback on UndoManager spec
(sorry for the long delay in responding, life is sometimes flaky for me right now) On Fri, Oct 28, 2011 at 3:54 PM, Ryosuke Niwa rn...@webkit.org wrote: But that manual transaction may be mutating DOM outside of the editable region. i.e. in the slide app case, you may have plane that's showing a list of slides. Since that's a part of the UI provided by the app, the DOM state of that UI may change over time without necessarily undoing or redoing insertions and removals of slides. So when you undo/redo an insertion of a slide, the exact change you make to the DOM may not be a mere restoration. Yet, the app still may want undo/redo in text fields to be implemented by UAs. What you're saying is that maybe there will be parts of the DOM that the author doesn't want the UA to touch? In that case, how about we let the author specify that UA undo/redo shouldn't affect certain subtrees? E.g., have the plane that shows a list of slides in div noundo or something like that. Then just like the UA doesn't undo/redo DOM changes outside the undo scope, it shouldn't undo/redo changes in a noundo region (or whatever you want the attribute to be called). This way, again, the UA will never be faced with the problem of undoing/redoing changes in a part of the DOM that the author may have tampered with. This is critical for making the APIs work reliably -- if automatic undo/redo can fail because of authoring bugs, authors won't want to use it. It also simplifies the API by getting rid of the distinction between automatic and manual transactions. Are you (or anyone) making a list of use-cases somewhere? If not, I guess I will, because it's really essential to designing a good API.
Re: [whatwg] Feedback on UndoManager spec
Okay, I created a wiki page with use-cases and requirements for them: http://wiki.whatwg.org/wiki/UndoManager_Problem_Descriptions I based it off http://rniwa.com/editing/undomanager-usecases.html, plus posts in this thread. I think that the current spec does not fulfill the following requirements that I suggest on that page: * The author must not be forced to deal with manually handling DOM state just because they want to handle non-DOM state. Currently, if I want the UA to automatically handle DOM state, I cannot provide unapply or reapply methods. This means that if I need to handle non-DOM state, like for a canvas editor, then I have to keep track of all my DOM changes too. I should be able to write a canvas editor and still let the UA handle all DOM state. This would mean allowing unapply/reapply methods to be provided for automatic transactions, with the UA undoing any DOM changes they cause. * If browsers try to merge changes themselves, the algorithm should be well-defined if possible. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results. The current spec doesn't solve this requirement, but it might not be solvable. I discuss that further below. Does anyone disagree with any of the requirements on that page, or think that there are any more requirements that need to be added? I think all that should happen at this point is allowing unapply/reapply to be supplied for automatic transactions, but make sure that any DOM changes they make are undone immediately so that the DOM doesn't fall out of sync. That solves one of the two requirements that (IMO) the current spec doesn't meet. On Mon, Nov 7, 2011 at 11:55 AM, Ryosuke Niwa rn...@webkit.org wrote: I don't understand what problem(s) you're trying to solve here. Even if we introduced noundo content attribute, there's nothing that prevents authors from not using that content attribute and modifying DOM directly. Okay, thanks. This is the key point I was missing. Just so I understand, what's supposed to happen here: * Some changes get made in an automatic transaction. * Some changes get made in no transaction at all, just a script calling DOM methods. * execCommand(undo) Is the resulting DOM just undefined? Why isn't it defined to be whatever the state was before the automatic transaction, so any intervening changes just get undone too? This seems to be what Gecko does. E.g.: data:text/html,!doctype html div contenteditableFoo/div script var div = document.querySelector(div); getSelection().selectAllChildren(div); document.execCommand(bold); div.innerHTML = bar; document.execCommand(undo); /script Firefox 9.0a2 produces the results I expected, i.e., Foo selected and not bolded. Chrome 16 dev re-adds the removed Foo, then unbolds and selects it, so you get bar[Foo]. Opera Next 11.50 just ignores the undo. Now consider this: data:text/html,!doctype html div contenteditableFoo/div script var div = document.querySelector(div); getSelection().selectAllChildren(div); document.execCommand(bold); document.body.appendChild(document.createTextNode(bar)); document.execCommand(undo); /script Opera seems to just ignore the undo. Chrome tries to cleverly merge it, and in this case succeeds, unbolding Foo without removing the bar. Firefox removes bar and also unbolds Foo, so again, it just restores the whole page's DOM state to what it was before the transaction it undoes. It looks like what Gecko does is include *any* DOM changes anywhere in the page automatically in the previous transaction. This makes sense to me, and it guarantees that changes can always be undone reliably. Is Gecko's behavior here bad? What disadvantages does it have? Can we work around those disadvantages while still meeting all use-cases, and keeping behavior performant *and* well-defined? Also, this noundo content attribute will be problematic inside contenteditable region because random elements that need to removed/moved may have this attribute. Yes, we'd have to be careful about what happens if the attribute is added/removed. However, it should be possible to do that, and then behavior will be well-defined, which is a big plus. Obviously, as you point out, this attribute is only really useful if the UA tracks *all* DOM changes as part of the last transaction, as Gecko seems to do. Otherwise it doesn't simplify anything. There's out-dated list at http://rniwa.com/editing/undomanager-usecases.html Thanks.
Re: [whatwg] Feedback on UndoManager spec
On Thu, Oct 27, 2011 at 6:10 PM, Jonas Sicking jo...@sicking.cc wrote: Why is it harder to remember one function name and one attribute name, than to remember to function names? Because the function names in this case must be in your code and they must be correct, or they won't work. That means that when you copy-paste code from another site, the name is guaranteed to be correct and descriptive. The name of a boolean parameter is only in the spec, and authors don't read specs, so they're unlikely to ever know the name in the first place. They won't have a chance to remember it. This would be solved if the parameter weren't boolean -- it could be a string that's equal to either apply or reapply, for instance. Boolean parameters are evil in general, as I've said before. I also don't like the second parameter of transact(). Would everyone be happy if there were no reapply() function, and apply() took a string argument that would be either apply or reapply? If the functions are similar, it will be like the status quo except without a hard-to-remember boolean parameter and without the temptation to copy-paste code to separate functions. If the functions are totally different, it's just an extra if/else. Does that sound good to everyone? On Thu, Oct 27, 2011 at 7:04 PM, Ryosuke Niwa rn...@webkit.org wrote: 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. It might cause compat issues if UAs don't handle such error cases interoperably, though. 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. Ah, of course: you might want undo/redo to handle state other than just the DOM. But why do we force the author to manage DOM state themselves just because they want to manage some non-DOM state? Why don't we have the UA always manage the state of the DOM within the undoscope, but call any unapply/reapply functions in addition to that? So how about this: get rid of the manual/automatic distinction entirely. Just have one type of transaction, with the following behavior. (I assume we have apply()/unapply()/reapply() with no parameters for any of them, for simplicity, but the same idea would work if we pass a parameter to apply().) * When the transaction is applied, call the apply() function, if any. Record all DOM changes within the undo scope. * When the transaction is unapplied, call the unapply() function, if any. Then undo any DOM changes that unapply() caused that were within the undo scope. Then undo the changes that were recorded from the original apply(). * When the transaction is reapplied, call the reapply() function, if any. Then undo any DOM changes that reapply() caused that were within the undo scope. Then redo the changes that were recorded from the original apply(). To get the equivalent of an automatic transaction, just don't specify unapply/reapply functions. To get the equivalent of a manual transaction, do specify them. The only limitation is that unapplying or reapplying a transaction can never affect the DOM within the undo scope except to undo or redo the original changes, but this seems like a good thing. Authors will be able to make state changes in things like canvas or JS variables, and can change DOM state outside the undo scope however they want, but can't incorrectly change things in the undo scope. Is there any disadvantage to this compared to the current spec? I really doubt authors will be able to get manual transactions right -- it's just too easy for some complicated function to make some unexpected changes to the DOM for some reason. The UA should silently fix these, not just let the DOM become inconsistent with the undo history. Also, this means we don't have to leave behavior undefined for fixing up manual transactions that don't undo themselves properly. On Thu, Oct 27, 2011 at 7:10 PM, Ryosuke Niwa rn...@webkit.org wrote: 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. Perhaps we should define this in DOM4 instead of your spec, but I don't think your current definition is good enough. It requires every implementer or author to go through DOM 3 and make inferences. It's easy to make mistakes, or there might be things that are ambiguous. It's much better for a specification to state things exactly, so that it's as easy as possible to check that it's correct. Defining things imprecisely or indirectly shifts work from spec writers to spec readers, which is a
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Fri, Oct 28, 2011 at 3:06 AM, Jonas Sicking jo...@sicking.cc wrote: I'm not sure what you are trying to say. I think he means to say that custom IDL properties added by authors have to persist. I'm not sure there's any official name for them in standards, but I've heard them called expando properties. Perhaps DOM4 should define a name for them, for convenience's sake.
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Fri, Oct 28, 2011 at 12:07 PM, Mike Taylor
michaelaarontay...@gmail.com wrote:
I would prefer if it returned the DOMTokenList, to enable chaining like:
foo.toggle('bar baz').remove('bat');
Same for the rest of the DOMTokenList methods, as well.
foo.add('bar').remove('baz');
See also https://github.com/jquery/standards/issues/13 for relevant
discussion.
This is not how existing DOM methods tend to behave, but in general I
support adding it in more places, because it's very useful for methods
that mutate the object they're called on.
Re: [whatwg] Feedback on UndoManager spec
On Fri, Oct 28, 2011 at 12:59 PM, Ryosuke Niwa rn...@webkit.org wrote: I don't want string because then I'd have to do: if (mode == 'reapply') instead of if (isReapply) and the former is much more verbose. It's a few extra characters. I really think the increase in clarity is worth it. Boolean parameters are much more confusing, and should be avoided wherever possible. That won't work for a collaborative editor because undo/redo may need to make DOM changes other than just restoring DOM states. For example, changes made by other users can't be undone/redone by the local user, and those changes may also have mutated the highest node affected by automatic transactions. And authors still want to be able to sync the list of undo/redo items with UAs (e.g. to enable undo item in Edit menu). Okay, good. That's another use-case. I think it would be helpful if you added these use-cases to the spec so that it's easier to see why it's designed the way it is. Now I suggest that automatic transactions behave as I described, also running reapply/unapply but undoing any DOM changes they do. Thus for things like tracking canvas state, the author can still use them safely. For collaborative editing, I suggest that we avoid the problems due to mixing manual and automatic transactions by making it per-UndoManager instead of per-transaction. So instead of an isAutomatic property for transactions, have methods on UndoManager, maybe enableManualTransactions() and disableManualTransactions(). Then when one of these is called, clear the transaction history. That way, we don't have to worry about undefined behavior when manual and automatic transactions are mixed, and we still satisfy all use-cases. Collaborative editors won't want to use automatic transactions, right? For the said reason, this won't address all use cases for manual transaction. But I've started to think that maybe calling unapply and reapply after undo/redo is a good thing even for automatic transactions. That'll let authors fix toolbar/widget status and maybe fix up selection (to match Opera/WebKit on Mac). I think this is a good idea. But that's the whole point of manual transactions. It is there to let authors make arbitrary changes in undo and redo. Right, but we need to be careful not to give authors more power than necessary. We should only be exposing functionality justified by the use-cases. Otherwise we make things more complicated for everyone. If we can't think of any good reason authors would want to mix manual and automatic transactions, for instance, we shouldn't allow it if we can avoid complication that way. If we later find that authors really do want to mix them, we can add new features at that point, but we shouldn't before then. Something that just occurred to me: the specification needs to handle textareas and inputs. Their values aren't part of the DOM, but they need to be tracked in the undo history. Their values should be part of DOM state for our purposes, even though changing them doesn't fire mutation events.
Re: [whatwg] Feedback on UndoManager spec
On Fri, Oct 28, 2011 at 2:47 PM, Ojan Vafai o...@chromium.org wrote: On Fri, Oct 28, 2011 at 11:36 AM, Aryeh Gregor a...@aryeh.name wrote: It's a few extra characters. I really think the increase in clarity is worth it. Boolean parameters are much more confusing, and should be avoided wherever possible. +1. I'm also OK with the argument if it's a string. Jonas? Another use-case: a (possibly collaborative) slide editor (e.g. Google Presentations). Imagine that each text box in a slide is a contentEditable. You want adding/removing textboxes and/or slides to be manual transactions, but actual text editing in the text boxes to be automatic. And you want all this in the same undo stack. Well, there are two possibilities: 1) When undoing the manual transactions, the author intends to get back to the exact same DOM as before. In this case, it's no problem if the UA enforces this automatically: it's just doing what the author wanted. 2) When undoing the manual transactions, the author does not intend to get back to the exact same DOM as before, maybe because someone else has modified it. In this case, automatic transactions are useless anyway. The UA's best effort will not be what the author wants, particularly if it's undefined. For instance, in a collaborative editor, if someone else has added some text that shouldn't be undone, the UA will fail randomly. Thus the author cannot rely on automatic transactions and will have to do the merge resolution themselves. In other words, even in a collaborative editor, what would be a case where automatic transactions would actually be useful? They'll just fail randomly with undefined behavior. So suppose we have some hypothetical collaborative editor. What's an example sequence of mixed automatic and manual transactions that would occur where the automatic transactions will reliably work, but the manual transactions can't also be automatic?
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 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
[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
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] 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: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] Normalization of user selections
On Tue, Jun 28, 2011 at 1:38 PM, Aryeh Gregor simetrical+...@gmail.com wrote: I've updated the spec to require this: https://bitbucket.org/ms2ger/dom-range/changeset/b9ca1640aeee http://html5.org/specs/dom-range.html#apis-for-the-browsing-context-selection:-the-selection-interface The boundary points of a selection's range must now always be a Text or Element node that descends from a Document. Trying to call collapse(), extend(), selectAllChildren(), or addRange() in a way that would make a boundary point not a Text or Element node will throw INVALID_NODE_TYPE_ERR, and trying to make it a node that doesn't descend from a Document will throw INVALID_MODIFICATION_ERR. I'll add more specific constraints on user-created selections later. Does anyone think this is a bad approach? If so, feedback would be appreciated. I eventually reverted this change: http://dvcs.w3.org/hg/editing/rev/f8c262d61ccc The reasons are explained in the commit diff. I couldn't get away with saying Selection endpoints can't be Comments or such unless I defined what to do to the Selection if one of its Ranges changed, such as due to a DOM mutation. That would be a lot more complicated than just speccing the IE/Gecko behavior, it wouldn't match any browsers, and it would add only dubious utility. So now the spec matches IE/Gecko again -- any Range can be passed to addRange(), and a reference to that Range will be added to the Selection.
Re: [whatwg] Undoscopes inside an editable region should ignored
On Mon, Oct 10, 2011 at 9:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Allowing authors to define an undoscope inside an editing host appears to be troublesome because user editing actions can modify the subtree of the host in very complex ways, and it's hard to understand which node may be mutated as a result of some editing actions or execCommand. Given that, I propose to ignore undoscope content attributes or assignments to undoScope IDL attribute if the content attribute is added to or the IDL attribute is set to true for an editable element. This sounds reasonable. The content attribute should be made non-conforming in that case. Perhaps the IDL attribute should throw on setting? Maybe better to just do nothing, but that doesn't give the author any idea of what's wrong. Furthermore, I propose to continue to ignore undoscope content attribute and keep undoScope IDL attribute false when the element becomes non-editable in the future (e.g. by removing contenteditable content attribute of its ancestor). Such a quirk is needed to avoid creating and destroying undoManager as a result of style recalculation in Mozilla and WebKit because both engines support -webkit-user-modify and -moz-user-modify to toggle editability. That sounds bad. To an author, it means that some element won't be an undoscope for no discernible reason. I guess you just mean that existing undoscope content attributes will be ignored, but if the author sets the IDL or content attribute after the element is editable, it will still work? It seems confusing. What do you intend to do if an element with the undoscope attribute becomes editable? This could also happen due to style recalculation, right? Are you not going to check in that case either, so it's possible to get editable undoscopes after all? Why do Gecko/WebKit support a CSS property for this anyway? It also means you can't support :read-write for contenteditable, because that would make selectors depend on style resolution. Is it just a convenience measure so that you don't have to implement efficient property inheritance a second time? Could you make the property ignored in user stylesheets, at least, so that the only way authors can make things editable is contenteditable/designMode? I really don't think we want to standardize this -- it's not something authors should be using CSS for.
Re: [whatwg] Undoscopes inside an editable region should ignored
On Tue, Oct 11, 2011 at 12:58 PM, Ryosuke Niwa rn...@webkit.org wrote: It also means you can't support :read-write for contenteditable, because that would make selectors depend on style resolution. Is it just a convenience measure so that you don't have to implement efficient property inheritance a second time? Could you make the property ignored in user stylesheets, at least, so that the only way authors can make things editable is contenteditable/designMode? I wanted to get rid of it but couldn't due to compat. issue. There are too many applications that depend on -webkit-user-modify at the moment. I really don't think we want to standardize this -- it's not something authors should be using CSS for. Right. I don't think we should but that doesn't mean we can drop the support. Is that WebKit-only content, or web content too? Could you turn it off just for web content? Or do you not like introducing discrepancies like that between webpages and other pages?
Re: [whatwg] Three concerns regarding HTML5 form validation
On Wed, Sep 28, 2011 at 11:00 AM, Rob Crowther robe...@boogdesign.com wrote: I think this is exactly what this StackOverflow user was asking for: http://stackoverflow.com/questions/7548612 Basically he wants to trigger validation for each section of the form as the user goes along. Doesn't Firefox already behave this way natively?
Re: [whatwg] Making selectionDirection platform-independent
On Mon, Sep 26, 2011 at 12:34 PM, Ryosuke Niwa rn...@webkit.org wrote: No. The property is platform dependent. It's just that UAs on Windows and Linux don't use none in most cases. Do they ever use it?
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Tue, Sep 20, 2011 at 10:13 PM, Ryosuke Niwa rn...@webkit.org wrote: void apply(in boolean isReapply) I haven't been following the substance of apply vs. reapply etc., but as I said before, could you not make this a boolean argument? How are authors supposed to remember whether it's apply(true) that means reapply or apply(false)? You should instead make the argument something that contains the word reapply somewhere, like maybe a space-separated list of case-insensitive tokens where any token other than reapply is ignored. So you'd do apply(reapply) if you wanted to reapply, and other flags could be added later if desired. This is both more comprehensible and more extensible.
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Wed, Sep 21, 2011 at 12:58 PM, Ryosuke Niwa rn...@webkit.org wrote:
So apply, unapply, and reapply are callback functions supplied by authors
and called by UAs.
e.g.
myUndoScope.undoManager.transact({
apply: function() {alert('done');},
unapply: function() {alert('undone');},
reapply: function() {alert('redone');}
})
the above code inserts a new transaction which pops up alert('done'), and
then alert('undo') and alert('redone') when the transaction is undone or
redone. But undo/redo of a transaction is done through undoManager.undo,
undoManager.redo, or execCommand so authors don't ever call unapply or
reapply functions directly in those normal use cases.
Oh, I see. Okay, then, having a boolean argument isn't such a big
problem. return true and return false aren't as bad, because you
only have to deal with one at a time.
Re: [whatwg] [editing] queryCommand(Indeterm|State|Value) for commands where they make no sense
On Mon, Sep 19, 2011 at 12:37 PM, Ryosuke Niwa rn...@webkit.org wrote: Not throwing makes sense to me (at least for now). What value should they return though? State/indeterm should return false, value should return . For state/indeterm, this is what IE/WebKit/Opera do (Gecko throws). For value, it's what Gecko/Opera do; IE and WebKit return boolean false, but that's the wrong type. and false are equal anyway if you don't use ===, so I don't think it will be a compat problem to switch from false to . For the value of commands like bold that take a state, I'm going to say return always. This might not be compatible for everyone, but we have four different behaviors here: IE returns true or false, Gecko throws, WebKit returns true or false, Opera returns always. So it's going to have to be incompatible with someone. I don't like WebKit's behavior because returning false is very confusing (it evaluates to boolean true), I don't like IE's behavior because it returns a boolean instead of a string, I don't like Gecko's because it throws. So in this case I think we should be like Opera, and make the value behave like in other cases where it doesn't make sense. That's the most consistent path.
Re: [whatwg] [editing] queryCommand(Indeterm|State|Value) for commands where they make no sense
On Mon, Sep 19, 2011 at 1:50 PM, Ryosuke Niwa rn...@webkit.org wrote: Sounds like a reasonable solution to me. For what's worth, I think WebKit used to return false all the time so I don't think this will cause a huge compat. issue for us. I've changed the spec (warning, large diff): https://dvcs.w3.org/hg/editing/rev/3a8b64badbdb
Re: [whatwg] [editing] New conformance tests
On Thu, Sep 15, 2011 at 6:34 PM, Ehsan Akhgari eh...@mozilla.com wrote: Maybe we can split these tests into multiple files, with one master file which loads them all, one by one, in iframes or something? I just tried running them under a debug build of Firefox, and they take about three times as long as an optimized build for me (it was a bit more than 3 minutes for me, but I have a pretty fast machine!) I can do that. I have a bug filed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=14069 These are all fine. I'm planning to write a script which gathers the current status of the tests, and then use that every time that I update the test suite to get the expected result set. I'll I care about at this point is that we don't change something in Gecko which changes these expected test results (either making some tests that passed before fail or vice versa) without understanding why. Okay, good. In the mean time, do you know about the licensing of the stuff under http://dvcs.w3.org/hg/html/file/tip/tests? I want to make sure that they have a compatible license so that we can import them into our tree. This page implies they're all available under three-clause BSD (in addition to the no derivative works W3C Test Suite License): http://www.w3.org/html/wg/wiki/Testing/Submission/ http://www.w3.org/Consortium/Legal/2008/03-bsd-license.html
[whatwg] [editing] queryCommand(Indeterm|State|Value) for commands where they make no sense
I'm still using the whatwg list, because discussion on whether using public-webapps is okay is (of course) still ongoing: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1402.html What should the correct behavior be in the following cases? * queryCommand*(insertimage). Neither state, value, nor indeterm make sense for insertImage. * queryCommandState(fontname). Value and indeterm make sense, but state does not. * queryCommandValue(bold). State and indeterm make sense, but value does not. Browsers behave as follows: * queryCommand*(insertimage): IE10PP2 and Chrome 15 dev return boolean false for all three (even value, it seems). Firefox 8.0a2 throws NS_ERROR_FAILURE for indeterm and state, and returns for value. Opera 11.50 returns boolean false for state and for value (it doesn't support indeterm at all). * queryCommandState(fontname): IE10PP2, Chrome 15 dev, and Opera 11.50 return false. Firefox 8.0a2 throws NS_ERROR_FAILURE. * queryCommandValue(bold): IE9 returns the same as the state: boolean true or false (not strings). Firefox 8.0a2 and Opera 11.50 return the empty string. Chrome 15 dev returns the state cast to a string, so either true or false. (Actually, I think I caught Opera 11.50 returning boolean false in one case, but I'm not sure what triggered it.) So there are two related questions here: 1) What should the value be for commands where only state really makes sense, like bold or italic? IE returns the state as a boolean, WebKit returns the state cast to a string, and Gecko/Opera return the empty string always. I think WebKit is clearly wrong here. true and false are just going to be confusing -- authors will say things like if (document.queryCommandValue(bold)) and be confused when it always is true. When they alert() the values, it will look like booleans. If the value is going to correspond to the state, it should evaluate to the same thing when cast to a boolean. IE is also unreasonable, because it returns booleans. It makes more sense for queryCommandValue() to have a fixed return type, namely string. IE's behavior doesn't really gain anything anyway, since it just duplicates the functionality of queryCommandState(). That leaves the Gecko/Opera behavior. I don't like it much -- it means that calling queryCommandValue(bold) just does nothing useful, so it indicates a bug in the author's code. It would make the most sense to throw an exception. But that might not be web-compatible, since no one does it. Does anyone want to try and find out? The spec currently says to throw in this case, but it's a compat break that might not be justifiable. So my current thought here is to throw an exception if we think the compat risk is acceptable, and failing that always return an empty string. Thoughts? (The spec currently requires throwing an INVALID_ACCESS_ERR exception.) 2) What should happen for indeterm, state, and value for commands where they make no sense? IE, Chrome and Opera all return a fixed dummy value for all three (well, except Opera doesn't support indeterm). Gecko throws for indeterm and state, but returns the empty string for value. As with value, I think throwing makes the most sense. If we throw for (1), we should definitely throw here. If we return an empty string for (1), then I'd say we should return an empty string for value, and false for indeterm/state, for consistency's sake. Again, thoughts? (I don't think returning boolean false for value is worthwhile, since returning the empty string is a more consistent return type and behaves practically the same.) I think the exception-throwing behavior is preferable in principle, but for compat, I suspect the right behavior is to always return boolean false for state and indeterm, and for value. This basically matches everyone but Gecko for commands where none of them make sense, and matches Gecko/Opera for the value of commands where only state makes sense. Throwing doesn't match anyone except Gecko, and then only in some cases. If others agree, I'll change the spec and tests accordingly.
Re: [whatwg] [editing] New conformance tests
On Fri, Sep 9, 2011 at 12:48 PM, Bjartur Thorlacius svartma...@gmail.com wrote: It freezes surf as well, and then crashes it (though that's clearly a bug in surf and maybe JavaScriptCore). Opera runs it fine, but the chrome is slowed down severely. The results are quite a bit bigger than my copy buffer, and polite ML messages, though :) Maybe my Opera build is just plain outdated, but I felt the numbers might be interesting either way. Opera 10.60 Internal. Build 6386 for Linux. Compiled on Jun 30 2010 by gcc 4.3.2 (ABI: 1002) for GNU libc 2.7. Time elapsed: 2:38.857 min. Summary Found 56720 tests 13685 Pass 43035 Fail Apparently I need a faster CPU: Time elapsed: 15:38.332 min.Summary Found 56734 tests14107 Pass42627 Fail By way of comparison, in Firefox 8.0a2: Time elapsed: 4:51.723 min. Summary Found 56734 tests 14759 Pass 41975 Fail Annoyingly, it looks like Opera is failing some tests solely due to not following the HTML5 serialization algorithm. I rely on innerHTML heavily for the tests. I could try to work around these failures, but hopefully IE and Opera will migrate to HTML5 serialization soon enough that it won't be worth the effort. On Tue, Sep 13, 2011 at 6:25 PM, Ehsan Akhgari eh...@mozilla.com wrote: This looks really interesting. Do you think this conformance suite is in a good stage for browser vendors to integrate it in their test suites? I'm interested in integrating this into Mozilla's test suite to make sure that we don't regress anything covered by these tests without realizing it. It's very likely that some of the tests are wrong, or that they match the spec but the spec is wrong. With that kept in mind, yes, it should be suitable for integration into browser test suites. It uses James Graham's testharness.js, so I should think you'd want to make some bridge that lets that integrate into your test suites, then plug these in. testharness.js is designed for this use-case, but as far as I know, only Opera uses it that way at this point. You might want to speak to James about it if you want to work on integrating it. There are lots more tests that use testharness.js, such as these: http://dvcs.w3.org/hg/html/file/tip/tests/submission/AryehGregor/reflection http://dvcs.w3.org/hg/webapps/file/tip/DOMCore/tests/submissions/Ms2ger And more are being written regularly. This is now the preferred test format for the HTML and WebApps WGs, so it would be great if browsers supported it.
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Mon, Sep 12, 2011 at 8:19 PM, Jonas Sicking jo...@sicking.cc wrote: Could you please supply an example where the apply/reapply split leads to cleaner or otherwise better code than using a boolean argument? Boolean arguments are evil and should be avoided wherever possible. It's impossible to figure out from the call signature what they do. Instead, have an argument that accepts a string argument consisting of space-separated tokens, or something like that. Even named constants are better than boolean arguments.
[whatwg] [editing] New conformance tests
I've had some type of tests around for a while now, but they weren't suitable for implementers. I've now recoded and reformatted them so that they output a table of results using James Graham's testharness.js. The link is here, but WARNING: it will run script continuously for a few minutes, which will freeze Firefox (Chrome is fine): http://aryeh.name/spec/editing/conformancetest/runtest.html I haven't tested it yet in IE or Opera, but obviously that's fairly high on my priority list. I also intend to break it up into more manageable chunks so it doesn't freeze the tab or browser for quite so long. The tests are documented in the specification itself: http://aryeh.name/spec/editing/editing.html#tests There are currently 56,720 individual tests, some of which contain several independent assertions. Most of the tests are queryCommand*()-related, since I generally run six such tests (indeterm, state, value; before, after) for each command executed. I would greatly appreciate feedback if anyone spots tests that don't seem to give reasonable or correct results -- that could signify a bug in the test suite and/or the spec. This is just a first pass, I still have a bunch of cleanup to do. Nevertheless, feedback appreciated!
Re: [whatwg] Terminology: managed vs. manual transactions
On Tue, Aug 30, 2011 at 12:12 PM, Ryosuke Niwa rn...@webkit.org wrote: Mn... I've never had that problem. e.g. .net framework uses the term managed code to mean the code that's garbage-collected by the framework and unmanaged code to mean the code that manually manage memory among other things. That's true, but many web authors aren't going to be familiar with .NET, or any non-garbage-collected language. Managed definitely sounds ambiguous to me, and I've been exposed to more non-garbage-collected code than most web authors. Mn... Jonas requested that I add separate method on undoManager for manual and managed transactions so I'd rather not name one of them userAgentTransact since the term user agent doesn't seem to be popular outside of standard bodies. I agree that user agent is a very standards-y term. Maybe browser-managed transaction and script-managed transaction?
[whatwg] Terminology: managed vs. manual transactions
In the UndoManager spec http://rniwa.com/editing/undomanager.html, there are two types of transactions: managed and manual. Managed transactions are handled by the browser, while manual ones are handled by the author. The term managed keeps confusing me, though. I never remember if it means managed by the browser, or by the author. Why don't you rename managed transactions to automatic transactions or something like that?
Re: [whatwg] Empty elements
On Sun, Aug 28, 2011 at 12:26 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: The word void, though used even in the validator's message, is at least misleading if not incorrect. The correct word is empty. Void is correct: http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#void-elements The interesting question is: Where do the normative rules say that self-closing syntax must not be used for other than empty elements? http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#start-tags The XHTML serialization rules say, at http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#the-xhtml-syntax as follows: Those are relevant only to documents served with an XML MIME type. Documents served with a text/html MIME type must obey the HTML syntax rules, not XHTML. I couldn't find where the spec says this normatively, but there's an informative note at the top of the HTML syntax and XHTML syntax sections. If you're serving a document with an XML MIME type, foo/foo is equivalent to foo / for any value of foo. The validator won't distinguish and neither will UAs, so use whichever you please. They're entirely different with an HTML MIME type, and that cannot be changed at this point due to compatibility.
Re: [whatwg] [editing] Additional miscellaneous commands
2011/8/18 Alfonso Martínez de Lizarrondo aml...@gmail.com:
Showing all whitespace would be the most complete solution, but if the rest
of browsers could behave like Opera and handle this, that would be enough
for most of the people:
br:before {content: \B6;}
That doesn't sound like a great solution, since it doesn't work for
line breaks created by things like p. There's no visible difference
between divfoo/divdivbar/div and foobrbar, so it's confusing
to have them behave differently. I'm not surprised that browsers
don't agree here, though, because br is pretty magical and
underspecified.
on the other side it's clear that besides the .execCommand a good Editing
spec should state or hint about other features that the browsers must
implement to behave properly (like showing the caret so the user knows where
he's typing, enable the user to select parts of the content,...). These
might look trivial, but iOS5 seems to be the first mobile browser that will
behave good enough so that both CKEditor and TinyMCE will enable the support
for it (check the comments in
http://code.google.com/p/android/issues/detail?id=8253 about the Android
browser)
A browser that provides a perfect implementation of all the execCommands but
doesn't allow the user to type or select is worthless for editing.
There's not much need to specify things that are completely obvious.
If Android's browser doesn't support contenteditable, that means they
haven't gotten around to it yet, and writing in a standard that they
have to do it isn't going to make them do it any faster. Standards
are necessary to allow implementers to implement the same thing when
they want to implement it at all, not to make them implement something
that they aren't interested in right now.
Re: [whatwg] [editing] Additional miscellaneous commands
Thanks again for your feedback. 2011/8/16 Alfonso Martínez de Lizarrondo aml...@gmail.com: Ups, sorry, I thought that the Comments buttons would open a feedback form but anyway I haven't read all the spec and I just used Ctrl+F to check for some of those commands and I didn't find anything. Ah, I can see how that would be confusing. I renamed Comments to View comments: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=60e4f1e6 Is that clearer? You probably won't find it with Ctrl-F, because it's hidden by default, but Ctrl-F on the HTML source should work. From the list that I've mentioned previously: Inline table editing is available only in Mozilla, it's nice in order to add or remove rows. Bug filed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13806. I expect this would be pretty complicated relative to the benefit, so I don't think I'll get to it soon, but it's definitely a feature for a future version. Autodetection of URLs is a feature of IE and since IE9 it's possible to disable it. Many people expect that when they type an URL it gets converted automatically into a link. Bug filed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13807. I might get to this relatively soon, since it's a fairly visible feature that users are likely to expect. Of course there are other people that don't want it. I've written previously in other sites that the best way to handle it would be to get an event with the new created link, that way the editor could alter some properties (like setting a @rel or @target) if needed. This is a general issue with commands. I've seen authors forced to work around this with insertImage too: they insert an image with a URL like ##insertedimage##, then do something like document.querySelector(##insertedimage##) to find it, then set the URL to the one they actually want and set classes and things. It might indeed make sense to have special events for various kinds of autocreated or command-created elements. The Respect visibility features is aimed at being able to have something with display:none and the user can edit it, if it's hidden then the editor has to provide some other way so that the user can edit that content that might be displayed later with javascript. That's one CSS rule, no? At the very least, providing a list of all the known commands of all the browsers can help to use those little hidden secrets. And of course a big warning on those that shouldn't be used anymore like it's done with the useCss. In those cases it might be enough to provide a list of commands that aren't really useful and so the implementors can move to try to remove them as you suggested. I might add a list at some point of commands that are deliberately not specified, for which implementers should drop support. There are many things that are possible with javascript and stylesheets, but I think that the goal was to make things simpler. For example your algorithm is implemented in Javascript and AFAIK, both CKEditor and TinyMCE don't use .execCommand to apply styling while editing, they also use their own javascript routines. So applying the same statement there's no need that the browsers change their implementation because it can be done with javascript. Absolutely, the goal is to make things simpler for authors. However, if something is already very simple to do with CSS and JavaScript, we don't need to add an extra way to do it. All the commands that are currently specified are *incredibly* difficult to do well -- I've spent hundreds of hours over the course of months specifying them, and there are still major deficiencies in a lot of them. But if you can make display: none things display with one CSS rule, so that's not something we need an extra way to control. Yes, that sounds fine; we just have to be sure that everyone agrees that such CSS property also applies while editing a document (and maybe say that by default it should be enabled for both images and tables in editable elements) Also, maybe the behavior of the browser should be slightly different while editing. I think that the resize property might have been thought for textareas so the user can adjust the size (and ignore designers that don't use the pages that they create) and so they aren't really worried about the exact size, but while editing a content it's nice to see the resized dimensions like done in Firefox. And of course, resizing a picture by the corner should respect the width/height ratio, not like IE does. Thanks, I updated the bug with this further info. Related to CSS, one feature that people request and that from my POV should be done with CSS is the ability to see the formating blocks, that's easy to do with most of the elements by using a little background image in the stylesheet and some border, but Opera used to be the only one able to format br, and that's what people are requesting, to see a glyph where a line ends like they can do in
Re: [whatwg] Search-suggestions without scripting
On Wed, Aug 17, 2011 at 4:12 AM, Alexandre Morgaut alexandre.morg...@4d.com wrote: I like the idea of a declarative way to support autosuggestions OpenSearch already made a successful specification supported by most browsers http://www.opensearch.org/Specifications/OpenSearch/1.1 That's an interesting point. There's no reason that autosuggest for browser URL bars and search inputs has to be any different. Given that all the infrastructure here is already present, a new attribute like suggestions=http://path/to/opensearch; would be all that's needed. It would be relatively easy for browsers to implement, and trivial for webpages to use if they're already using OpenSearch. I don't think this has to be related to datalist -- just have a new attribute on input.
Re: [whatwg] [editing] Additional miscellaneous commands
2011/8/16 Alfonso Martínez de Lizarrondo aml...@gmail.com:
Hi
The drafted specs defines most of the common features of contentEditable,
but there are other commands that have been left out
enableInlineTableEditing
enableObjectResizing
AutoUrlDetect
RespectVisibilityInDesign
...
I have some of these noted in the Comments drop-down at the bottom here:
http://aryeh.name/spec/editing/editing.html#issues
I've looked at MSDN documentation and compiled a list of supported
commands, but I seem to be missing some. Do you know of a more
comprehensive list? Also, it would help a lot if you (or anyone else)
could point out which specific commands sound especially useful.
IE used to had a bunch of poorly documented commands, but the important part
for me is that those extra commands might enable some behaviors that are too
hard to emulate by javascript, and if they can be added to the spec, then
hopefully they will be available in the future for all the users.
I agree with this general point, but it's really best to have specific
examples to work with. It's almost surely not worth it to
reverse-engineer all the IE commands here. For instance,
RespectVisibilityInDesign is something we can do without -- visibility
should always be respected, so that what the user sees is what they
get when they save. If authors want to let users edit particular
invisible things, they can make them visible using a stylesheet rule.
One basic example is resizing. Currently Webkit browsers doesn't allow the
user to resize a picture, table,.. that it's placed in the contents. Some
people might not want that behavior at all, others might prefer to enable it
only for tables but not images, and I think that instead of putting that
burden on the javascript editor, it should be the browser the one that takes
care of that with a basic command to turn it on/off and then firing the
needed events when something like a resize starts or ends like IE does.
Might the CSS resize property be the best way to do this?
http://www.w3.org/TR/2004/CR-css3-ui-20040511/#resize
Then authors could do img { resize: both } or similar. This is much
more flexible than a global on-off switch, because you could allow the
user to resize some things but not others. For instance, a forum that
allows users to insert custom images and also smilies might want them
to be able to resize the custom images but not the smilies, and it
could do that with an appropriate CSS selector. I'd have to update
the spec to say that if the user resizes editable things, the browser
needs to actually change the DOM to add height/width attributes or
properties.
I filed a bug on this:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13795. Please feel
free to file bugs for any other specific features you'd like me to
look into. Note that right now I'm mostly focused on fixing up and
stabilizing core functionality, so I might not get around to adding
new features for a while.
Re: [whatwg] Search-suggestions without scripting
On Sun, Aug 14, 2011 at 3:26 AM, Timo Beermann timo.beerm...@googlemail.com wrote: The search-suggestions of search-fields as in Google or Wikipedia should be able without scripting, only with HTML/CSS. Because some users deactivate Scripting (for security or whatever other reason) and on other computers (school, university, work,...) you are not able to change the settings, even if you want to. E.g. I use NoScript and only allow scripting on very few trusted sites, that really need it. Scripting is generally necessary to get dynamic content. datalist can be used to provide search suggestions, but they'll be static if script is disabled. Proper suggest-as-you-type functionality is precisely the sort of thing that JavaScript is always going to be required for. Things that can already be done in script are usually only be made into declarative features if they meet a very high bar: they must be *very* commonly used, and there must be substantial benefit to typical users (not just ones who disable script) from having them available as declarative features.
Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
On Mon, Aug 8, 2011 at 5:03 AM, Simon Pieters sim...@opera.com wrote: Things that are visibility:hidden are not focusable. I don't think that can be changed without compat problems. If visibility:hidden things are not focusable, I guess it makes sense to not make it selectable, too. (Possibly Web pages also expect visibility:hidden things to let clicks go through?) Sense aside, visibility:hidden is not selectable in any current browsers, right? Testing with div contenteditablefoospan style=visibility:hiddenbar/spanbaz/div, Firefox 7.0a2 and Opera 11.50 both allow placing the cursor in the hidden text as normal, letting you type and delete and so on. Chrome 14 dev jumps over it, so if your cursor is at b[]az and you go back it jumps to foo[]. IE10PP2 just ignores the visibility and makes it visible (??). So it seems like treating it like regular text is the best match for current browsers, as well as the simplest, unless people have other test-cases that are relevant.
Re: [whatwg] Discrepancies between HTML and ES rules for parsing an integer or float
On Fri, Aug 5, 2011 at 1:57 AM, Jonas Sicking jo...@sicking.cc wrote: It would make sense to me to match ES here. The main concern is of course website compat. Could someone detail what the differences would be compared to what implementations/the HTML5 spec do now? As far as I know, the only difference between the HTML and ES algorithms is handling of non-ASCII whitespace: ES treats it as whitespace, HTML does not. Specifically, ES treats StrWhiteSpaceChar as leading whitespace: http://es5.github.com/#x15.1.2.2 That includes any Unicode space separator (Zs), which in particular changes over time (which seems to be Hixie's main objection IIUC). HTML uses skip whitespace: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#signed-integers Which if you follow the breadcrumbs means only [ \t\n\r\f]. So it's almost never going to make any difference in practice, we're talking only about corner cases. I have a simple test-case at http://www.w3.org/Bugs/Public/show_bug.cgi?id=12296#c4 that shows all browsers strip leading \x0b (vertical tab) when converting DOM attributes to ints, which matches ES and not HTML. For parsing floats this would not seem like a problem though since attributes containing floats is relatively new IIRC. Yes, that's correct. There's definitely no compat issue here with floats, but really there's not going to be any with ints either, since it's going to be exceedingly rare that anyone will put Unicode whitespace in DOM attributes that are reflected as integers and then rely on them working. So it's just a question of if we'd prefer the algorithms to match or not.
Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
On Thu, Aug 4, 2011 at 5:22 PM, Ryosuke Niwa rn...@webkit.org wrote:
I see. It's an interesting point. In WebKit, we're quite inconsistent in
relying on CSS/rendering engine and pure DOM. This is an inherent issue in
RTE because user would like the editor to work like WYSIWYG yet we have to
produce conforming markup :(
Yeah, it's a problem. The basic issue is that there are no standard
interfaces to query things like what's the height of this br? or
are these two nodes in the same line box? from CSS, so I have
nothing to reference and browser engines might not even know the
information. So I hack around it with a mix of pure-DOM definitions,
and just not defining things clearly.
Right. But you definitely don't want to place a caret / selection end point
inside a node with visibility : hidden. So to that extent, you'd have to
mention it somewhere (definitely when you're normalizing selection end
points).
Hmm, I'm not sure. Text that's visibility: hidden looks the same to
the user as text that's color: transparent, so why should it behave
differently for selections?
I still don't understand exactly when sibling criteria returns true and
which node new parent instructors returns. Where are these algorithm
defined?
The wrap algorithm takes three inputs: a list of nodes, and two
algorithms. The callers provide the sibling criteria and new parent
instructions algorithms. Take a look at the callers of the wrap
algorithm and hopefully it will be clearer. Do you have any
suggestions on how to make this clearer in the spec? Maybe the note I
just added at the beginning
http://aryeh.name/spec/editing/editing.html#wrapping-a-list-of-nodes
helps?
Not really. Surprisingly or not, it's a very common technique used
throughout WebKit's editing code. I just wished we could avoid adding br
if we were to only remove them later.
That would be nice, but it's hard to figure out sometimes. Like if
the selection is in p{}br/p, and a script does insertHTML to add
foo, we want to remove the br, but if it adds !-- foo -- we
want to keep it. And if you select p{br}/p and insertHTML to
add !-- foo --, we need to make a new br regardless. I could
write it so that it checks after the fact if the br is extraneous,
but it seemed easier to just remove it in the beginning and then add a
new one later if needed.
CSS makes me sad sometimes. :(
I see. That's very unfortunate. Can we defined the list in terms of the
phrasing content though? Or define phrasing content in terms of your
definition?
There are complications. For instance, HTML defines a, ins, and
del as being phrasing content only if they contain only phrasing
content, which isn't useful for our purposes. The idea of phrasing
content is meant to be concerned with authoring conformance, and it
doesn't seem well suited to what we need. But I'd like to see
something worked out in the long term to harmonize them, yeah. It's
just not an immediate need, it can wait.
I personally think Gecko and Opera's behavior makes more sense here.
I don't. Partly it's for the reason I give in the comment next to
backColor's action: it's
incoherent from a user perspective. For instance, if you try it on
paragraphs the background will have big gaps where the margins are. If
you try it on an inline element that's a child of the editing host, it
will do nothing or apply the background to everything or such, even
though such an inline element is visually indistinguishable from one
sitting inside a div. This would only make sense if we take
considerable effort to ensure that block elements all have no margins,
or if we wrap things in a div if they have margins, or something like
that.
background-color on block elements doesn't make sense from a WYSIWYG
perspective, because it behaves differently based on whether an
element has margin vs. padding, or whether there's a wrapper around a
block or just br's, etc. These differences normally aren't visible
in rendering, so making command behavior depend on them is confusing.
Also, the way the spec defines it is the way both IE and WebKit
behave, so that's a large majority of the market and is probably the
most compatible.
This is a WebKit bug that I've been intending to
fix: https://bugs.webkit.org/show_bug.cgi?id=11089.
Okay, changed: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=b599880c
I don't think so although I might have missed something. I just think that
introducing the concept of typing style might make the spec easier to read
and understand.
I don't like the use of the word style here, because it doesn't fit
for createLink. I could change it from state override and value
override to typing state and typing value, I guess. But it
doesn't just affect typing, either: it also affects the return value
of queryCommandState()/queryCommandValue(). Thus override, because
it overrides the normal definition of state/value.
See the comment next to inline command activated values for
Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
On Tue, Aug 2, 2011 at 8:31 PM, Ryosuke Niwa rn...@webkit.org wrote: I've read a part of sections 7 and 8 but I've kind of lost here. The spec is very detailed and I can't really get a high-level view of what will happen. It might be helpful to have some high-level summary of what it tries to do for each algorithm something like one at the beginning of 7.6. I've added a whole bunch of high-level summary: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13633 Tell me if there are any parts where it could use more.
Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
On Wed, Aug 3, 2011 at 5:06 PM, Ehsan Akhgari eh...@mozilla.com wrote: On 11-08-03 4:13 PM, Aryeh Gregor wrote: Mike Smith has been kind enough to add a component to the W3C Bugzilla for the editing spec, in the WebApps WG product. From now on I'll use it for tracking feedback so I can be organized about things that I can't fix right away. The link to file a bug is: http://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWGcomponent=HTML+Editing+APIs I'll still respond to all e-mail feedback. Is it possible to get a unique QA contact (or default CC address) for this component please, so that people who are interested in watching it can watch that email address instead of member-webapi-...@w3.org? Would this be possible, Mike?
[whatwg] Discrepancies between HTML and ES rules for parsing an integer or float
Hixie just WONTFIXed two bugs that I thought might be of interest: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12220 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12296 Basically, HTML defines some algorithms for parsing integers, floats, etc., which are used in converting DOM to IDL attributes for reflection (among other things): http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#numbers The algorithms for parsing integers and floats are almost exactly the same as ECMAScript's parseInt() and parseFloat(), down to some of the language being copied word-for-word, but with subtle differences involving (at least) whitespace handling. IMO, this is bad for several reasons: * It's confusing to both authors and implementers to have multiple almost identical algorithms. Nobody's going to expect the discrepancy in the corner cases where it matters. * It's confusing to people reading the spec for there to be these extra algorithms defined, whose relationship to the ES algorithms is not obvious. The HTML and ES algorithms are written in entirely different styles and it's hard to tell what the differences are from side-by-side inspections. * In at least some cases, all browsers match ES and none match the spec -- see http://www.w3.org/Bugs/Public/show_bug.cgi?id=12296#c4. * Browsers will have to maintain the ES algorithms as well as the HTML algorithms, so even if the HTML algorithms are superior, it doesn't save anyone the effort of understanding or implementing the ES algorithms. So I think HTML should just defer to ES here. Hixie disagrees, and has resolved both bugs twice now, so I'm not going to reopen them myself at this point. However, I'd like to hear from implementers whether they're willing to implement the spec as it stands, or whether they want the spec algorithms to be identical to ES's algorithms.
Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
Mike Smith has been kind enough to add a component to the W3C Bugzilla for the editing spec, in the WebApps WG product. From now on I'll use it for tracking feedback so I can be organized about things that I can't fix right away. The link to file a bug is: http://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWGcomponent=HTML+Editing+APIs I'll still respond to all e-mail feedback. On Tue, Aug 2, 2011 at 8:31 PM, Ryosuke Niwa rn...@webkit.org wrote: Feedback on selections 5 through 7: The definition of collapsed line break isn't clear. Maybe it's br immediately before the end of a block? Unfortunately, that's not good enough if we want it to be correct in all cases. For instance, the br in pspanbr!-- foo --/span/p behaves like a collapsed line break for CSS purposes. Maybe we could just let the algorithm be wrong in those cases, if we can't come up with a better definition. The problem is that a real definition would depend very heavily on CSS. This is why there's a big red box in the spec . . . Isn't this essentially the collapsed line break and a br inside a block where br is the sole visible node? Sorry, I don't understand what you're saying here. The definition of visible should definitely take display: none and visibility: hidden into account. Also, you should take collapsed whitespace into account. e.g. br is invisible even though there are Text nodes before and after br. CSS2.1 spec section 16.6.1 has some elaboration on how whitespace is collapsed. visibility: hidden shouldn't be taken into account, I don't think. Such nodes still take up space, they just don't get painted, so they don't behave like real invisible nodes. I definitely need to take collapsed whitespace into account, and display: none. I filed a bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13631 Step 3 in remove extraneous line breaks before seems redundant because we traverse the tree in the reversed tree order in step 4. I'm not sure what you mean. Step 3 is While ref has children, set ref to its lastChild, and step 4 is While ref is invisible but not an extraneous line break, and ref does not equal node's parent, set ref to the node before it in tree order. Suppose you have spanfoobr/spanpbar/p and the algorithm is invoked with ref equal to the p. First we set ref to the span in step 1. Then in step 3 we set it to the br. Then step 4 does nothing, because the br is an extraneous line break. Then in step 5 we remove the br. Without step 3, ref would still be equal to the span. What are sibling criteria and new parent instructions in 6.2? I changed To wrap a list node list of consecutive sibling nodes, given sibling criteria and new parent instructions, run the following algorithm. If not provided, sibling criteria match nothing and new parent instructions return null. to To wrap a list node list of consecutive sibling nodes, run the following algorithm. In addition to node list, the algorithm accepts two inputs: an algorithm sibling criteria that accepts a node as input and outputs a boolean, and an algorithm new parent instructions that accepts nothing as input and outputs a node or null. If not provided, sibling criteria returns false and new parent instructions returns null. I also changed sibling criteria and new parent instructions to use var instead of dfn/span, to match other variables. Does that make it clear? http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=2992f823 Also where would new parent be inserted if new parent's parent was not null? Or will it stay where it was? I clarified in a comment: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=5771e7c0 Does it make sense now? I'm not sure why we'd need to add br's so aggressively in this algorithm Basically every time I add a br, it's because I found a case in tests where there was some bug otherwise. As far as I know, every time a br is added, it's needed to stop two lines from running together -- I avoid adding unnecessary brs and in fact remove them in a lot of places. If you look closely at the conditions, these br's will only be added when you're wrapping in block elements. Things like if you have blockquotefoo/blockquote[bar] and the author runs indent, it has to become blockquotefoobr[bar]/blockquote not blockquotefoo[bar]/blockquote None of these should normally do anything if you're wrapping in something like a b. Are there any specific cases that you think are unnecessary? Can 6.3 be tied with phrasing content concept used in the rest of HTML5 spec? See the comment at the beginning of the allowed child algorithm, beginning with TODO: This list doesn't currently match HTML's validity requirements for a few reasons:. The biggest problem with phrasing content is that it's only defined for valid elements, but we need to also care about things like font for compatibility. But as I say in the comments next to the definition for name of an element with inline
Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
On Tue, Jul 26, 2011 at 5:26 PM, Aryeh Gregor simetrical+...@gmail.com wrote: Anyone reviewing the spec should be advised that I put extensive rationale in HTML comments. If you want to know why the spec says what it does, check the HTML source. I plan to change this to use details or such in the near future. Since the comments were relatively hard to spot, I've rewritten them to be visible as you read the spec. There are now tons of Comments buttons floated to the right, which contain lots of rationale and other commentary. Some are pretty terse and are reminders to me as much as anything, others are detailed explanations of the reasons behind various decisions (some inordinately long, with the toggle lists one being the most egregious). I probably introduced some editorial mistakes in the course of converting the comments, but they should be extremely helpful for review.
Re: [whatwg] input type=password... restrict reading value from JS?
On Fri, Jul 29, 2011 at 9:53 PM, Bjartur Thorlacius svartma...@gmail.com wrote: So there are two use cases for reading user passwords: * client side password strength indicators ** telling users if their passwords conform to site specific password restrictions - arguably bad practice - IMO better achieved with declared regular expressions If you're doing useful password strength checks, regular expressions won't cut it. For instance, you'll want to check against dictionaries. Regex is only useful for crude and ineffective checks like must be at least six characters long with mixed-case letters, numbers, and punctuation (= Abcd0! is okay, effervescentarcheopteryxattack is not). I don't think anyone but the receiving server should be able to read my password. JavaScript acts as the agent of the receiving server. This is a cornerstone of the web security model. The server is what sent you the JavaScript, so it's trusted to act on behalf of the site. There's no way you're going to paper this over by trying to remove one or two minor privileges from JavaScript. (Yes, there are a few cases where we do this as an XSS defense-in-depth measure, like HttpOnly cookies, but only for very narrow things where it makes sense.) This is one of the reasons some people disable JavaScript. Most don't, as they don't want to stop JavaScripts from doing other more useful things. If we disable just stuff like this we can bring some security to the folks that have JavaScript enabled (such as me). No you can't. JavaScript can replace arbitrary page content. You can't work around that without crippling it. Are XHR submits of passwords common and important enough to outweigh the security cost of scripts having access to all passwords in their document(s)? Yes. We can't stop them without breaking the web. I propose disallowing changing the action attribute of forms with password inputs. We can't do that without breaking the web. There are going to be countless sites that rely on being able to create forms in JavaScript, which includes setting their action attribute and includes forms with password inputs.
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, Jul 29, 2011 at 7:24 PM, Ian Hickson i...@hixie.ch wrote: My overarching point, however, is that this is a UI issue, and not an authoring issue. The overarching counterpoint is that in-page UI *is* an authoring issue, because authors want to control exactly how their page looks and behaves. Browser/chrome UI issues shouldn't be standardized, but page UI issues absolutely should (at least in many cases).
Re: [whatwg] [editing] Caret Position Access Methods
On Fri, Jul 29, 2011 at 11:13 AM, Dan Gisolfi giso...@us.ibm.com wrote:
On behalf of the Open Cooperative Web Framework Project
(http://opencoweb.org), with respect to the HTML Editing APIs specification
(http://aryeh.name/spec/editing/editing.html), it would seem the current
version of the spec lacks APIs for getting / setting the caret
position.
As far as I can tell, this is covered by the Selection interface in DOM Range:
http://html5.org/specs/dom-range.html#apis-for-the-browsing-context-selection:-the-selection-interface
Anne van Kesteren, Ms2ger, and I have agreed that it probably makes
sense to move the Selection part of DOM Range into the editing spec
and the Range part into DOM Core at some point, but for now it's in a
separate specification.
An example scenario for such a requirement (addition of such methods) would
be the following:
When developing an cooperative web enabled rich-text-editor, whereby
multiple simultaneous users can co-author shared content, the editor must be
able to allow each participant to get/set caret/cursor position in order to
reflect the multiple positions of each active author in a cooperative web
session.
The Selection interface and getSelection() will allow you to inspect
and modify the selection (and cursor position, which is just one side
or other of the selection) of the current user, meaning the place that
will be affected when the user types or such. Is this all you need,
or is there something missing from it?
On Fri, Jul 29, 2011 at 2:07 PM, Dan Gisolfi giso...@us.ibm.com wrote:
My point herein and motivation for the suggestion is that this functionality
(get/set caret) is available in the textarea element. Using a textarea
element you can get/set caret position via get/setSelectionRange(). These
two methods should be implemented for a contentEditable div or the likes.
Within a contentEditable div, there is no way to [a] tell where the caret is
in relation to the text, such as the index; [b] direct the caret to a
specific position within the text.
getSelection() is very similar to the selectionStart, selectionEnd,
and setSelectionRange() properties on textareas. It's more
complicated, though, because rich text is more complicated than plain
text. Examples:
Collapse the selection and set the cursor to the beginning of a specific node:
getSelection().collapse(node, 0)
Select characters three through five in a Text node, that's the first
child of a specific element:
var range = document.createRange();
range.setStart(element.firstChild, 3);
range.setEnd(element.firstChild, 5);
getSelection().removeAllRanges();
getSelection().addRange(range);
Alternatively (simpler but does not work in some browsers):
getSelection().collapse(element.firstChild, 3);
getSelection().extend(element.firstChild, 5);
Retrieve the first range in the current selection:
var range;
if (getSelection().rangeCount) {
// There is some cursor or selection
range = getSelection().getRangeAt(0);
// range is now a Range object that you can look at
} else {
// Nothing is selected and there is no cursor position
}
If you see something missing from the Selection APIs that would be
useful to you, please say so. This list is fine for feedback on DOM
Range.
Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
On Wed, Jul 27, 2011 at 7:51 PM, Ryosuke Niwa rn...@webkit.org wrote: WebKit treats any font-weight above or equal to 600 as bold because that's what user sees, and boldness is a binary concept in execCommand; Firefox 5 appears to do the same. WebKit compares colors in rgb/rgba format; e.g. red is first parsed as rgb(255, 0, 0). Firefox 5 seems to does the same as well. WebKit compares font sizes in legacy font size used in font element; See CSSStyleSelector::legacyFontSize or legacyFontSizeFromCSSValue in EditingStyle.cpp Okay, I've now defined precisely how values have to be compared (in two different ways), and painstakingly used them everywhere they're necessary: http://aryeh.name/tmp/editing/editing.html#equivalent-values This should be well-defined now. On Thu, Jul 28, 2011 at 4:31 PM, Ryosuke Niwa rn...@webkit.org wrote: WebKit fires those events :( I don't know why we do that. I think it's a WebKit bug but I'm just pointing that out in the case there are some websites out there that depends on this quirky behavior. Just cut/copy/paste for now as far as I know. How do the cut/copy/paste commands work at all in WebKit? I tried using them but they did nothing. queryCommandSupported() returns false for all three. Is there some special switch?
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson i...@hixie.ch wrote: Looking specifically at datagrid's ability to fall back to select, I agree that it's not necessarily doing to be widely used, but given that it's so simple to support and provides such a clean way to do fallback, I really don't see the harm in supporting it. I haven't looked at datagrid yet, so I can't comment. I think he meant datalist. datagrid was axed quite some time ago and hasn't made a reappearance that I know of.
Re: [whatwg] Specification of window.find()
On Wed, Jul 27, 2011 at 6:55 PM, Tim Down timd...@gmail.com wrote:
There's also the perennial problem of dealing with non-visible text
(c.f. Selection.toString(), innerText), which some browsers handle (a
quick tests suggests WebKit searches non-visible text and Firefox
doesn't).
True. Of course, that's a rabbit hole I've mostly managed to avoid
going down so far.
Also, don't forget that you're in the habit of writing this
sort of code. Knocking that kind of code out quickly is beyond what a
large percentage of web developers are capable of.
Right, but that's why we have libraries like jQuery. If it's in
demand and it can be done in JavaScript, libraries can do it, and then
we don't want to make browsers do it too unless either it's an
extremely common use-case or they can do it better somehow. Or they
have to for compat.
There is no reason why your algorithms can't
work on non-editable nodes, so why require the user to change such a
fundamental property of the DOM (even temporarily)? I'd prefer an
alternative mechanism for specifying whether a command should apply to
only editable content that is part of the editing API. In my
execCommand implementation, it's specified as a property of an options
object passed to execCommand(). If that's not an option, another
command could be used, similar to the styleWithCSS command, to switch
between modes. applyToNonEditable, or something.
Having a behavior switch like styleWithCSS is a possible option. The
problem I have with that kind of switch is that it breaks down if two
scripts on the same page are both relying on the switch being a
particular value: you can't rely on the current state of the switch
unless you run it before every single command execution. I saw at
least one execCommand()-using library that did exactly that, running
styleWithCSS *and* useCSS before every single command.
Defining an extra argument to execCommand() would be possible, but I'm
leery about it, because it already has one useless boolean argument
that no browser but IE supports. What we could consider is
overloading it with a form like execCommand(command, options), where
options is an object, so you could do execCommand(forecolor, {value:
red, styleWithCSS: false, restrictToEditable: true}) or something.
But it's awkward to have to specify the same options all the time, and
the syntax is incompatible and doesn't fall back gracefully.
It's definitely worth considering at some point, though. I added a
TODO: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=aff4441e
Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
Thanks to both of you for the feedback! On Wed, Jul 27, 2011 at 7:51 PM, Ryosuke Niwa rn...@webkit.org wrote: WebKit treats any font-weight above or equal to 600 as bold because that's what user sees, and boldness is a binary concept in execCommand; Firefox 5 appears to do the same. Yes, bold is not a big problem. If you look at the bold command section, it explicitly defines the values bold, 600, 700, 800, or 900 as corresponding to on, so it's simple string comparison. The bigger problem is things like colors and sizes, where there are lots of units that are related in complicated ways. What I'd really like to do is have CSSOM define a reliable way of uniquely serializing CSS values, and then say that two values are equal if they serialize to the same thing. But I guess for now I should just make up my own definition. For most things it's pretty straightforward in principle, but it still needs to be specced. WebKit compares colors in rgb/rgba format; e.g. red is first parsed as rgb(255, 0, 0). Firefox 5 seems to does the same as well. Yeah, that's the obvious way to do it. If I have to write the definition for this, I guess I'll just say two CSS colors are equal if their R/G/B/A channels are all equal. WebKit compares font sizes in legacy font size used in font element; See CSSStyleSelector::legacyFontSize or legacyFontSizeFromCSSValue in EditingStyle.cpp I more or less reverse-engineered that to define queryCommandValue(fontSize) -- translate the computed font-size to pixels, then round to the nearest corresponding legacy font size. Other browsers do different things that are less useful. But there are cases when I want to compare CSS values for equality more precisely. For instance, per spec, if you have span style=font-size:largefoo[bar]baz/span and run execCommand(fontSize, false, 4), it does nothing. WebKit seems to break up the span and add a new span or font element, but this adds extra clutter. However, if you have span style=font-size:18pxfoo[bar]baz/span then the spec says to break up the span, because 18px != large, even though queryCommandValue() says the same thing for both. Throwing SYNTAX_ERR might cause a backward compatibility issue because the UAs don't throw an error now. We can probably throwing console messages first to give authors some grace period to transition. Yeah, this was a bad idea. The only case where anyone throws exceptions for bad values is Opera with formatBlock. I've removed this: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=ff9f4629 Don't know why I added it in the first place. For font element vs. span with style issue, we could add another boolean flag that forces UAs to toggle font-element; i.e. add StyleWithFont command. I guess. 3.2: Prefix webkit- doesn't seem natural given all editing commands use Camel case. Maybe Ms, Gecko, WebKit and Opera? e.g. WebKitFontSizeDelta. But again this might cause a backward compatibility because we do implement few editing commands that are not in the spec and they are not prefixed. I copied this from HTML5, and I think at least Opera has some commands with this syntax, but you're right it doesn't make much sense. I've changed it: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=e9369d6c 3.3: The return value of queryCommandEnable depends on beforecut, beforecopy, and beforepaste events and selection state in WebKit; WebKit returns false if default actions are prevented in those events or selection is not a range. Firefox 5 appears to do the same for selection but doesn't seem to fire beforecut, beforecopy, and beforepaste. How does WebKit know if those events will be prevented or not, without running the handlers? If the page runs queryCommandEnabled(), nothing actually happened, so surely WebKit doesn't fire any events? Also, are you only talking about the cut/copy/paste commands, or other commands too? On Thu, Jul 28, 2011 at 7:06 AM, Michael A. Puls II shadow2...@gmail.com wrote: At the end of section 4, there's: the state of insertOrderedList and insertOrderedList might be true both before and after calling Is one of those supposed to be insertUnorderedList? Yeah, thanks. Fixed: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=eb346d01 At the beginning of section 5, there's: An editing host is a node that is either an Element with a contenteditable attribute set to the true state, or the Element child of a Document whose designMode is enabled. What does Element child refer to specifically in the latter? Is it the HTML body element or is that implementation-specific? It just means what the literal words imply: any Element that is the child of a Document whose designMode is enabled. The Nodes model http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#nodes-model implies that any Document will always have either zero or one child that's an Element. If one exists, it will be returned by document.documentElement. For HTML
Re: [whatwg] Nested list
(Ian pointed out this old thread to me that he hadn't yet responded
to, so I'll respond now.)
On Thu, Jul 2, 2009 at 6:05 PM, Ryosuke Niwa rn...@google.com wrote:
Hi, I just realized that in HTML4.01 spec, DTD doesn't seem to allow
nested OL or UL without LI. See
http://www.w3.org/TR/REC-html40/struct/lists.html#h-10.2 In fact, the
nested list example is marked deprecated. But in practice, all major
user agents produce nested list when execCommand(Indent...) is
executed. Is there any chance we can standardize nested lists, and in
particular, what UA produce?
I opened a bug about this a while ago:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12609
For example, all major browsers (Firefox, IE, WebKit) produce
slightly different versions of HTML when indenting item 2 in the
following HTML (assume it's content-editable):
ol
ol id=u1li id=i1item 1/li/ol
li id=i2item 2/li
ol id=u3li id=i3item 3/li/ol
/ol
In particular, many UA remove arbitrary id attributes.
If you remove the whitespace nodes (which currently confuse my
algorithms in lots of places -- it's a known issue), it produces
olol id=u1li id=i1item 1/lili id=i2ite[m] 2/lili
id=i3item 3/li/ol/ol
according to my implementation. This is because of the following
steps in the indent algorithm at the time of this writing:
* Let tag be the local name of the parent of first node.
* Wrap node list, with sibling criteria matching only HTML elements
with local name tag and new parent instructions returning the result
of calling createElement(tag) on the ownerDocument of first node.
http://aryeh.name/gitweb.cgi?p=editing;a=blob_plain;f=editing.html;hb=e4c523de#indent
Since the sibling criteria only require the sibling to have local name
tag (in this case ol), without regard to attributes, it's considered
valid for merging. Since both the previous and next siblings match
the sibling criteria, the next sibling is merged into the previous
sibling, so the resulting element has the id of the original first
element.
Chrome 14 dev merges them but keeps the id of the second list, not the
first. Firefox 7.0a2 merges into the second list, and ignores the
first list even if it has no id -- it seems to ignore previous
siblings if there's a legitimate next sibling. Opera 11.50 gives the
same output as the spec. IE10PP2 merges the three items into one list
that has no id at all. I think that the spec (= Opera) is reasonable
here -- anyone disagree?
I added a few tests to my test suite based on this feedback:
http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=d4233f8f
On Mon, Jul 13, 2009 at 7:01 AM, Simon Pieters sim...@opera.com wrote:
I think this is a bug in execCommand('indent') and should be fixed in
browsers.
I disagree. I found when writing my spec that having ol/ul nested
inside li complicates a lot of things needlessly, because the
ol/ul is visually part of the parent ol/ul and not the li.
I wound up aggressively normalizing list items so that if they contain
ol or ul, those are broken out to become siblings in any case
where it might cause problems:
http://aryeh.name/gitweb.cgi?p=editing;a=blob_plain;f=editing.html;hb=e4c523de#normalize-sublists
I don't see that this has any semantic problem. We can simply define
the semantics of ollifoo/liollibar/ol/ol as being the
same as those of ollifooollibar/ol/ol.
On Thu, Sep 3, 2009 at 8:29 PM, Ian Hickson i...@hixie.ch wrote:
There are lots of bugs that need fixing with execCommand(); I don't see
why this wouldn't be one of them.
I've considered the issue carefully and determined that it's HTML5's
authoring requirements that should change here, not browsers'
execCommand() behavior. Basically, to avoid extra branching, we want
to ensure that all nested lists we deal with are consistent, either
all nested directly or all nested inside li's. Having them nested
directly makes things simpler.
For instance, suppose you have markup like
ollifooollibar/olbaz/ol and the user outdents the middle
item. This needs to be a special case: you have to notice that you're
a descendant of an li, break that into two, and stick the ol in
between. If you first normalize and make the markup look like
ollifoo/liollibar/ollibaz/ol, outdenting the middle
item can completely ignore the outer list with no need for a special
case.
Or take another case: consider the markup,
ollifoolibarollibaz/ol/ol, and have the user select
bar and try to indent it. It looks like baz is a separate item,
so the user will expect it not to get indented along with bar. This
means you need to do a bunch of complicated stuff: first you need to
look for a previous list item to move things into (foo in this
case), then check if there's already an ol at the end of it, merge
into that ol if so, otherwise create a new ol, move the whole li
containing barbaz into the new ol, move the baz li out of its
ol, remove that. Or something like that. If I first normalize to
ollifoolibar/liollibaz/ol/ol, I can wrap the bar li
Re: [whatwg] [editing] Proposal: Undeletable elements within contentEditable
(Responding to some old feedback on editing from before I started work on it, which Hixie sent me.) On Thu, Jun 24, 2010 at 12:08 PM, Nikita Vasilyev m...@elv1s.ru wrote: The current version of spec http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#contenteditable does not define any way to make an element within contentEditable undeletable. I propose undeletable attribute: element.undeletable = true | false How should it work: div contenteditable span undeletablefoo/span /div When I focus on the div, select all the text, and delete it, the span element MUST be empty, but MUST NOT be deleted. This behavior would be very useful while building code editors. I'm building CSS editor with syntax highlighting and auto-completion based on contentEditable. undeletable attribute would help me a lot. I'm very reluctant to add such things, because it adds corner cases that vastly complicate processing and allow tons more room for bugs. It means every single algorithm related to editing needs to be aware of the attribute and check for it before deleting anything. This is already a big headache for contenteditable=false, which has tons of bugs in my algorithms and in browsers that I haven't even tried fixing systematically yet. Also, I don't know what use it would be to have the empty wrapper element hanging around. I've designed the editing algorithms to avoid leaving such things: the user can never focus them, typically, so they don't do much unless you're adding weird styles or such. If you really wanted this effect, though, I think span contenteditable=true should in theory do what you want. I've been designing my spec's algorithms based on the premise that an editing host should never be deleted or have its attributes modified, but it can be moved around if it's inside another editing host. There are probably loads of bugs in the spec, as I said, and browsers have a very different view of how things should work in practice, but that's my goal. I haven't given a lot of thought to nested editing hosts or nested non-editable content, though. I'm not sure what the use-cases are. It would help a lot if you could explain exactly what you want this for. 2010/6/24 Joseph Thomas jthom...@calpoly.edu: It seems like the ideal way to handle this would be to handle the MutationEvent (and cancel it, but unfortunately they are non-cancelable. Perhaps a set of cancelable events, i.e. UserMutationEvent. ( see http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mutationevents ) Mutation events are a massive headache and we're trying to get rid of them, so this isn't a feasible long-term suggestion. See the very long recent thread on the public-webapps list on this subject.
Re: [whatwg] DOM Range Deletions
(answering some old feedback on DOM Range that Hixie pointed me to)
On Tue, Jun 15, 2010 at 6:52 AM, Andrew Oakley and...@ado.is-a-geek.net wrote:
I've been trying to implement DOM Range but can't work out how ranges
are supposed to work under mutation.
This should now be more or less fully defined in the DOM Range spec,
with a pretty decent test suite:
http://html5.org/specs/dom-range.html#range-behavior-under-document-mutation
I wrote up the new definitions a couple of months ago. They aim to be
both precise and compatible with browser behavior, which means they
mostly match DOM 2 Range but differ in some respects.
In the following examples I use *this* to indicate a range being deleted
and slashes to indicate another range.
Section 2.6 - Deleting Content with a Range gives the example of
FOOX*YBARZ*W/BARQ/FOO - FOOX^BARW/BARQ/FOO
Section 2.12.2 - Deletions says:
If a boundary-point of the original Range is within the content being
deleted, then after the deletion it will be at the same position as the
resulting boundary-point of the (now collapsed) Range used to delete the
contents.
This is not what browsers do, and not what the new DOM Range spec
requires. DOM 2 Range treats deletions as deletions of ranges, but
browsers and DOM Range both treat deletions as node-by-node.
deleteContents() specially modifies the range you call it on so that
it's always collapsed, as is defined in detail:
http://html5.org/specs/dom-range.html#dom-range-deletecontents
Note how the last step is Set the context object's start and end to
(new node, new offset), so the range you call the method on is
changed differently from other ranges.
If you have a range FOOX[YBARZ]W/BARQ/FOO (using [] to denote
the endpoints), then the algorithm works as follows:
* If original start node is an ancestor container of original end
node, set new node to original start node and new offset to original
start offset. Original start node here is the Text node XY, and
original end node is the Text node ZW. The former is neither equal
to nor an ancestor of the latter, so this doesn't apply, and we go to
the other branch.
* Let reference node equal original start node. So reference node
is now the Text node XY.
* While reference node's parent is not null and is not an ancestor
container of original end node, set reference node to its parent.
Reference node's parent is FOO, which is not null, but is an
ancestor container of original end node. Thus we do nothing in this
step.
* Set new node to the parent of reference node, and new offset to one
plus the index of reference node. Thus new node is FOO, and new
offset is 1.
So the Range you delete will eventually collapse to
FOOX{}BARW/BARQ/FOO. Note that here I use curly braces
instead of brackets, to indicate that the endpoint of the Range is in
an Element node, not a Text node. The old DOM 2 Range standard is
unclear on that point, but my spec matches what browsers do.
We then have the example of:
PABCD *efgh The EMR*ange/EM ijkl/P
/ \
Goes to
PABCD EMange/EM ijkl/P
/ \
In the syntax I'm using, that's: PABCD [efgh T[[he EMR]ange]]/EM
ijkl/P, where I use single brackets for the range being deleted and
double brackets for the other, for lack of better syntax.
The new specification uses entirely different rules when the Range
being deleted is different from the one being modified, as I noted.
The deletion is treated as a sequence of separate mutations of
individual nodes. In this case, deleteContents() will do the
following:
1) Call deleteData() on the Text node ABCD efgh The , with offset 5
and count 9. This deletes efgh The and leaves only ABCD .
Current DOM Core defines this as replacing data with offset 5, count
9, and data , so we look at the When something replaces data of a
CharacterData node case at
http://html5.org/specs/dom-range.html#range-behavior-under-document-mutation.
The first boundary point of the [[ range has offset 11, and 5 11 =
5 + 9, so we hit the case For every boundary point whose node is
node, and whose offset is greater than offset but less than or equal
to offset plus count, set its offset to offset. Thus the offset is
set to offset, i.e., 5. This gives us:
PABCD [[EMRange]]/EM ijkl/P
2) Call deleteData() on the Text node Range, with offset 0 and count
1. This deletes R and leaves ange. We're replacing data with
offset 0, count 1, and data , and the second boundary point of the
]] range has offset 5, and 5 0 + 1, so we hit the case For every
boundary point whose node is node, and whose offset is greater than
offset plus count, add the length of data to its offset, then subtract
count from it. The length of data is 0 and count is 1, so we set the
new offset to 5 + 0 - 1 = 4. This gives us:
PABCD [[EMange]]/EM ijkl/P
The example in DOM 2 Range implies something more like PABCD
EM[[ange]]/EM ijkl/P. I agree this is wrong according to DOM 2
Range itself. DOM 2 Range is a
[whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
Since February, I've been working on writing a detailed specification for browser editing, primarily the document.execCommand() and document.queryCommand*() methods. These were created by Microsoft in the 1990s and were subsequently adopted in some form by all other browsers, and today browsers have to implement them to be compatible with web content, but no detailed specification ever existed. Interoperability is practically nonexistent as a result, which has driven all major content editing frameworks away from using execCommand(). Hopefully we can start to fix that and make these APIs a part of the web platform that just works. The current version of the specification is at http://aryeh.name/spec/editing/editing.html. It's about fifty pages printed, and supersedes the Editing APIs section of HTML http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#editing-apis (which is more like two pages). In the style of modern web specs, it is phrased in terms of algorithms that attempt to cover all corner cases unambiguously and leave no behavior undefined, and it tries to match the behavior of existing browsers to the greatest extent possible. At this point, it's stable and complete enough that I believe it's ready for serious review by implementers, and I would like as much detailed feedback as possible. There is a basically complete JavaScript implementation, which is used to produce expected results for a largely undocumented and entirely ad hoc test suite: http://aryeh.name/spec/editing/autoimplementation.html. I used the tests as an aid to writing the spec, and they probably aren't well suited to aid implementers in implementing it. I will probably get around to porting them to something like testharness.js at some point. I haven't tried testing my implementation on real-world sites, only on artificial input, so I don't know at this point how implementable it really is, but the JS implementation means that it at least has large parts that make sense. Anyone reviewing the spec should be advised that I put extensive rationale in HTML comments. If you want to know why the spec says what it does, check the HTML source. I plan to change this to use details or such in the near future. There are lots of minor known issues still left, but none that I thought was important enough that it needs to delay review. Feedback can be sent to the whatwg list, CCing me, with [editing] in the subject. (I'm also fine receiving feedback on public-html or public-webapps, but I don't know if the chairs would be okay with that, since it's off-topic.) I should be available to respond to all feedback promptly at least through the end of August. After that, I can't make specific guarantees about my availability, but I do plan to continue maintaining the spec in the long term. I've CCd or BCCd everyone who's commented on or contributed to this spec at some point.
Re: [whatwg] Specification of window.find()
On Wed, Jul 20, 2011 at 6:23 PM, Tim Down timd...@gmail.com wrote:
Yes, but it's significantly better than the alternative, which is to
write your own code to search for text that spans nodes.
It shouldn't be *too* hard to write that code. First do the search in
textContent and get a list of the offsets of all the results. Then
get a list of Text nodes, and iterate through them. Record the sum of
their lengths as you go, and when you get to the right place, store
the result. I'd guess it would be 20 lines or so. Something like
this (untested):
function findStrings(root, search) {
var offsets = [];
for (var i = root.textContent.indexOf(search); i != -1; i =
root.textContent.indexOf(search, i + 1)) {
offsets.push(i);
}
var results = [];
var treeWalker = document.createTreeWalker(root, NodeFilter.SHOW_TEXT);
var currentOffset = 0;
while (treeWalker.nextNode()) {
while (offsets.length
currentOffset = offsets[offsets.length - 1]
offsets[offsets.length - 1] currentOffset +
treeWalker.currentNode.length) {
results.push([treeWalker.currentNode,
offsets[offsets.length - 1] - currentOffset]);
offsets.pop();
}
currentOffset += treeWalker.currentNode.length;
}
return results;
}
Probably buggy, but something like that should work. (And hey, it's
19 lines, good guesswork.) Granted, if you wanted to do any kind of
normalization it would be more complicated to author, but also more
complicated to spec. So I don't see really a use-case here that's
strong enough to justify this, if we can get rid of it.
Agreed. My number two feature (well, it would make the top 5, at
least) would be removing the restriction on execCommand() only working
on editable content. This very use case shows that its usefulness
extends beyond editable content. The temporarily-switch-designMode-on
workaround is ugly, and destroys the selection in some browsers.
As I said elsewhere, I disagree. Wanting to only modify editable
content is an important use-case. It's easy to emulate the behavior
you want if that restriction is in place (temporarily turn on
designMode), but nearly impossible to emulate the opposite behavior if
it's not built in to start with. If execCommand() worked on any
content at all, then text editors would be permanently forced to use
iframes with designMode instead of being able to use contenteditable,
just to avoid the user randomly bolding or deleting interface text.
Also, it would mean that (for instance) execCommand(delete) works
differently from the backspace key.
If turning designMode on destroys the selection in some browsers,
that's a bug that can easily be fixed, and doesn't justify a change to
the spec. Changing specs to work around easily-fixed browser bugs
makes much less sense than just fixing the bugs. The only
disadvantage I see to requiring this is that it's error-prone: the
obvious way to do it is to turn designMode on and then turn it off,
which will have an unexpected side effect if it had already been on.
But that's a minor issue, and I don't see a good way to avoid it.
Why exactly do you not want to turn designMode on and off, other than
easily-fixed browser bugs? What do you think is ugly about it?
Re: [whatwg] Specification of window.find()
On Wed, Jul 20, 2011 at 6:14 AM, Tim Down timd...@gmail.com wrote: It's useful for custom search features. I've recommended it a few times on Stack Overflow for people wanting to highlight or somehow style all occurrences of a piece of text that may span nodes (it's this part that is the compelling feature). You can achieve the same using TextRange in IE. For example: http://stackoverflow.com/questions/5886858/full-text-search-in-html-ignoring-tags I think this is a valid use case. However, the implementation here doesn't do what you'd want: it selects the text, destroying any existing selection. You can work around it by preserving and then restoring the selection somehow, but it's not ideal at all. It would make much more sense to have a function that returned a Range or list of Ranges. Of course, for the use-case you posted, execCommand() would also have to work on Ranges instead of just the selection, but that should probably be feature #1 to add to it anyway . . .
Re: [whatwg] namespaces in html5
On Mon, Jul 18, 2011 at 10:33 AM, David Karger kar...@mit.edu wrote: Yes, we could, but it doesn't address the two objections I raised to data- prefix: 1. it isn't actually a data attribute, so prefixing with data seems odd (appearance; minor) It's data in the sense that it's being used to just store some info in the DOM without asking the browser to do anything extra with it. 2. there's no way to guarantee someone else won't use the same data-exhibit prefix, causing incompatibilities (functionality; major) There's also no way to guarantee someone else won't use the same URL for their namespace. But in either case, they almost certainly won't. If you're really paranoid, feel free to stick a GUID or domain name or something inside the names of all your data attributes. But the probability data-exhibit-* will ever collide with anything is already negligible. On Mon, Jul 18, 2011 at 2:23 PM, David Karger kar...@mit.edu wrote: As I interpret these words, data- attributes are intended to be delivered by a server for use by the javascript code that server delivers with the page. The exhibit attributes are not associated with any server, and are not associated with any particular data items being delivered by any server. Rather, they are part of generic software not associated with the server (see quote above) and handle _presentation_ of the content on the page. So, while it might be technically valid to use data- prefixes, it doesn't seem to fit the intention. I don't get how you're using these attributes. Do you expect browsers, search engines, or other consumers of HTML to treat them differently from any unrecognized attribute? Or do you intend that the attributes only be used by the scripts/stylesheets/etc. provided by your own site? If your use-case is the former, then you should propose the attributes for standardization. If the latter, it's exactly what data-* was designed for.
Re: [whatwg] input type=password... restrict reading value from JS?
On Mon, Jul 11, 2011 at 9:29 AM, Sean Connelly s...@pbwhere.com wrote: As a web developer, if I wanted access to the password, I would then avoid using the input type=password field, and create my own field that reads characters (perhaps via onkeyup), and fakes a password field visually. Then browsers wouldn't autofill it, which would defeat the nastiest attack here (stealing passwords without user intervention). But as noted, you can always submit the form, so it really doesn't help that much anyway.
Re: [whatwg] Using footer in blockquote for attribution
On Fri, Jul 1, 2011 at 4:26 AM, Simon Pieters sim...@opera.com wrote: blockquote is sectioning root. Oops. I stand corrected, never mind me.
Re: [whatwg] Using footer in blockquote for attribution
On Thu, Jun 30, 2011 at 11:50 AM, Oli Studholme whatwg@boblet.net wrote: blockquote p[block quote]/p footer— citea href=…[title of work]/a/cite/footer /blockquote This is incorrect according to the current definition of footer. Footer definition: “The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.” This means it's tied to the nearest section or article or such. It's not supposed to be specifically related to any other type of ancestor, like blockquote. Simon felt that “Content inside a blockquote must be quoted from another source” excludes footer. However the footer definition reads to me that footer is basically metadata *about* content (the non-footer or -header content of the sectioning or sectioning root element). Correct, but it's supposed to be metadata about the whole section, not about just its parent. However, I don't know if there's any specific way to mark this up. It's a common pattern, so it would be a good candidate for adding here: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#common-idioms-without-dedicated-elements It's useful to be able to put the author info in its own element so that you can style it differently.
Re: [whatwg] Normalization of user selections
On Fri, Jun 17, 2011 at 1:40 PM, Aryeh Gregor aryehgre...@gmail.com wrote: However, I'd still like to normalize author-set selections somewhat. At a minimum, for instance, we could guarantee that a selection's boundary point is always in a Text or Element node that descends from a Document. That would be a big simplification by itself. Does anyone object to that? I've updated the spec to require this: https://bitbucket.org/ms2ger/dom-range/changeset/b9ca1640aeee http://html5.org/specs/dom-range.html#apis-for-the-browsing-context-selection:-the-selection-interface The boundary points of a selection's range must now always be a Text or Element node that descends from a Document. Trying to call collapse(), extend(), selectAllChildren(), or addRange() in a way that would make a boundary point not a Text or Element node will throw INVALID_NODE_TYPE_ERR, and trying to make it a node that doesn't descend from a Document will throw INVALID_MODIFICATION_ERR. I'll add more specific constraints on user-created selections later. Does anyone think this is a bad approach? If so, feedback would be appreciated. One problem arose when I was doing this: what happens if the user gets a range with getRangeAt() and then alters it directly? In WebKit and Opera, getRangeAt() returns a copy, so this is no problem, but in IE and Gecko (and per current spec) it returns a reference. The simplest solution would just be to change the spec to match WebKit and Opera here, so getRangeAt() returns a copy of the range and addRange() adds a copy of the range. The only downside I can see is it's more complicated to alter a multi-range selection -- you'd have to remove and re-add a range to change it. But this doesn't seem like a big deal. Any objections if I change the spec to make these methods do copies?
Re: [whatwg] canvas drawing with singular transforms and zero-sized gradients
On Fri, Jun 24, 2011 at 10:52 PM, Robert O'Callahan rob...@ocallahan.org wrote: That's true if you call fillRect(), or fill() on a path that you've emitted while the current matrix is singular; the rectangle or path collapses to a single point (or line). I think it's completely clear browsers should draw nothing in those cases. However, my testcase emits a path while the matrix is non-singular, so the canvas-space path is definitely not collapsed to a point or line, then makes the matrix singular just for the fill operation. The question is then how the singular matrix affects the way the source color, gradient or pattern fills a non-empty path. I'm thinking of the source color, gradient, or pattern conceptually filling the plane (possibly almost all transparent in the case of a pattern), then being transformed by the matrix, then being clipped to fill the shape before being painted. Thus in my mind it's still being collapsed before being painted, even if it's just a solid color. That way a solid color is conceptually the same as a gradient with all color stops the same, or a solid-colored image. It seems like a useful invariant if the different styles behave the same reliably when they should logically be the same. That way authors can learn about patterns first (which is very concrete -- give it an image), then understand gradients and solid colors as special cases of patterns, and be consistently right. Authors might be surprised by the behavior in this particular case, but it's a fairly pathological case anyway, and it doesn't seem worthwhile to trade away consistency to get more intuitive behavior in this special case. I guess one big problem with this approach is you have a singularity at determinant zero, and that's really awkward because you can't rely on floating-point equality comparisons unless you allow some tolerance for rounding error, and in that case equality is no longer transitive. By my theory, a transformation matrix with determinant zero should result in solid colors doing nothing, but one with determinant e for any e 0 should result in the color being painted. This is obviously bad. So this is probably my pure math background showing through rather than a very useful contribution to the discussion. If the API were designed for mathematicians, now . . . On Fri, Jun 24, 2011 at 11:00 PM, Robert O'Callahan rob...@ocallahan.org wrote: If you set up a path covering the entire canvas, call ctx.scale(e, e) for infinitesimal e, and then fill with an image pattern, conceptually you're scaling the image to be incredibly small and then repeating it a very large number of times to fill the canvas. So I guess the logical behavior for e=0 would be to compute the average color of the image pixels and do a solid fill with that color, which would give you that consistency you're asking for. But is that worth implementing? No-one does that today. What does everyone do today instead? I'm guessing canvas doesn't currently define how you should apply the transformation matrix precisely, and in particular how to handle cases like this with subpixel detail. The same issue should arise for gradients with very small stops (as Tab points out), or ones with large stops that are scaled down a lot. If e were exactly zero, though, the logical behavior in my interpretation would be to paint nothing for any operation whatsoever, since the determinant is zero. But again, that's problematic.
Re: [whatwg] Outdated Implementation Statuses?
On Thu, Jun 23, 2011 at 5:55 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: The implementation statuses are not automatically generated - they're updated when someone cares enough to update them. Anyone can do so, though it's not very discoverable. Hold down Ctrl+Alt and double-click the status box, and it'll pop up a login prompt. Make an account, then you can change the statuses however you want. Maybe this should be documented clearly through a how to update link on the status boxes or such?
Re: [whatwg] canvas drawing with singular transforms and zero-sized gradients
On Fri, Jun 24, 2011 at 1:09 AM, Robert O'Callahan rob...@ocallahan.org wrote: Consider this testcase: http://people.mozilla.org/~roc/SingularCanvasMatrix.html It sets up a rectangle to fill, then sets the current matrix to a singular matrix (yy=0 in this case), then fills with different fillStyles. It's not clear from the spec how this is supposed to behave, and there's not much interop: There's an existing bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12705 I'm not familiar enough with the canvas API to have an informed opinion on what should happen here, but mathematically it makes sense to me that nothing should be drawn ever if the transform matrix is singular. Everything will be collapsed to line or point in that case, with zero width, so it's invisible. Even if it's just a solid color, conceptually you're collapsing the whole color-filled *plane* into something with zero width, so it should still be invisible. If you define different behavior for solid colors or gradients, doesn't that mean that they'll behave differently from if you used an image that looked exactly the same? That seems bad.
Re: [whatwg] What it means for attributes of input to apply or not apply
On Wed, Jun 22, 2011 at 11:50 AM, Edward O'Connor eocon...@apple.com wrote: The second bit (does not apply to the element), however, isn't clear. Is it a UA conformance requirement? What does it mean? I *think* it means that the placeholder= attribute has no effect on the rendering of input type=range. Does it also mean that the placeholder= content attribute shouldn't be reflected as an IDL attribute on input elements of type=range? In Safari 5, Firefox 4, and Opera 11, placeholder= gets reflected as an IDL attribute, regardless of the value of type=. It's reflected regardless of the type: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#dom-input-placeholder does not apply to the element could use clarification, though.
Re: [whatwg] Handling of collapsed whitespace in contenteditable
On Mon, Jun 20, 2011 at 6:05 PM, Ryosuke Niwa rn...@webkit.org wrote: Problem is that not all user agents, in particular, mail clients support white-space: pre-wrap. Good point. That's pretty much the final nail in the coffin. I'll specify something with nbsp's here, although I don't know how I'll make it work when runs of spaces span multiple text nodes. I'll add a note advising authors to use white-space: pre-wrap, although I doubt many will see or follow it.
Re: [whatwg] Handling of collapsed whitespace in contenteditable
On Mon, Jun 20, 2011 at 5:09 PM, Aryeh Gregor simetrical+...@gmail.com wrote: Does anyone have any suggestions on how best to handle this? It seems like no matter what we do, the best advice to authors would be to set white-space: pre-wrap on the editable region and the resulting editable content. So given that, I wish we could make this happen by default and avoid all the complexity. Failing that, I'll have to work out the least damaging way to use nbsp's here, but it's never going to behave right in some cases. I should add, by the way, that the latter seems very hard to get right without delving further into CSS details than I'd prefer. I can't think of any reliable and not-extremely-complicated way to test from JavaScript whether a space needs to be non-breaking or not in cases like bfoo[]/bbar, for instance. Indeed, in that case WebKit produces nbsp; instead of a regular space.
[whatwg] Handling of collapsed whitespace in contenteditable
If the user has the cursor positioned at the beginning or end of a
line, or immediately before or after a space, and hits space,
inserting a space at the current location would result in no visible
effect. Thus browsers will typically insert an nbsp in at least some
of these conditions, and/or convert surrounding spaces to nbsp's.
This causes all sorts of problems:
* An nbsp at the end of a line makes the last word longer, so when you
hit space, the last word on the line might jump to the next line.
Then when you type a letter, the nbsp gets converted to a regular
space and the word jumps back to the previous line. (I observed this
in Opera. IE and Gecko seem to have some special-case to avoid this;
WebKit avoids it with a more general hack that I'll note later.)
* An nbsp that winds up immediately before a word will cause the word
to be indented if it happens to start a line. Gecko seems to be very
careful to avoid this case, but all other engines do it sometimes.
* A long run of spaces of which some are spaces and some are nbsp's
can result in nbsp's at the beginning of a line. Thus if you type
three spaces in between two words for whatever reason, in some cases
the second word can be indented. This is probably not what users
want.
The behavior we really want here is to output regular spaces, and use
white-space: pre-wrap. This matches the word processors I tested
(Word 2007 and a moderately old OO.org): spaces don't collapse, and a
line break can never occur before a space, but it can always occur
after a run of spaces, and words followed by spaces don't get pushed
to the next line. (This is how pre-wrap behaves in IE and WebKit, at
least. In Gecko and Opera a long sequence of spaces will push the
preceding word to the next line, but I'd say that's a bug.)
If anyone here thinks it's practical to just set [contenteditable] {
white-space: pre-wrap } in UA stylesheets and output spaces all the
time, please say so. (I know the selector isn't quite right.) I
assume it's not, because it will make existing contenteditable areas
containing hand-authored content look wrong. If we did this, of
course, authors would have to set white-space: pre-wrap on the
resulting non-editable content as well, but at least then it would
work exactly as we want. If they don't set it, it won't look quite
the same as when the user edited it, but probably it wouldn't look
drastically worse.
It seems WebKit already does something kind of like this: in
contenteditable areas, line breaks are allowed at nbsp, they just
don't collapse. Thus user-created whitespace is partly nbsp's, and
breaks but doesn't collapse. Pre-existing author-added whitespace
doesn't contain nbsp and so collapses. And when you convert it to
non-editable content, it still doesn't collapse but breaking might be
different. This seems like a kind of evil hack, though.
Does anyone have any suggestions on how best to handle this? It seems
like no matter what we do, the best advice to authors would be to set
white-space: pre-wrap on the editable region and the resulting
editable content. So given that, I wish we could make this happen by
default and avoid all the complexity. Failing that, I'll have to work
out the least damaging way to use nbsp's here, but it's never going to
behave right in some cases.
Re: [whatwg] Handling of collapsed whitespace in contenteditable
On Mon, Jun 20, 2011 at 5:32 PM, Ehsan Akhgari eh...@mozilla.com wrote: There's a very good reason why existing browser engines have to resort to nbsp; hacks. It's the only practical way to make sure that foo__bar (s/_/ /) entered into an editable element would appear the intended way when the innerHTML of the editable area is submitted to a server and later displayed in another documents. Is that really such a problem? At worst, there will be annoying mismatches between the same content when it's editable and not editable. Usually these won't really mess up the document, but if the author notices and compares in a debugger, they'll easily be able to figure out that the different white-space value is what's causing the problem, and be able to fix it. WebKit already handles nbsp; differently in contenteditable and not -- have they received any complaints from authors about it? Granted, that discrepancy isn't as drastic as white-space: normal vs. pre-wrap. I'd have thought the bigger problem would be making hand-authored HTML contenteditable. pre-wrap would seriously mangle it if it uses any indentation, and there might be lots of that out on the web. On Mon, Jun 20, 2011 at 5:47 PM, Smylers smyl...@stripey.com wrote: Can you detect when an author has set white-space: pre-wrap, and specify that browsers have the sane behaviour in that case? That's effectively how it already works, except in IE. If the current element has white-space pre or pre-wrap, everyone but IE will just insert regular spaces. (IE only does this for pre, not other elements with non-default white-space values.) But in that case, the behavior would be entirely undiscoverable, so no one would use it. If pre-wrap were the default, the discrepancy in display between editable and non-editable would quickly lead savvy authors to figure out that they need pre-wrap on their content too.
Re: [whatwg] Hashing Passwords Client-side
On Mon, Jun 20, 2011 at 4:40 AM, James Graham jgra...@opera.com wrote: FWIW I disagree. The same argument could be used against client-side form validation since some authors might stop doing proper server-side validation. I agree, HTML5 forms provide a minor net security loss. However, the loss is fairly small and is easily outweighed by the non-security advantages. Here we have a proposal that only has security benefits, so if it's a net security loss by even a small margin, or even if it's only a small security gain, it's not worth it.
Re: [whatwg] Hashing Passwords Client-side
On Thu, Jun 16, 2011 at 5:39 PM, Daniel Cheng dch...@chromium.org wrote: A variation of this idea has been proposed in the past but was largely seen as undesirable--see http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026254.html. In general, I feel like the same objections are still true of this proposal. This proposal is considerably better formulated than that one was. But yes, in the end, the only real benefit is that the user can confirm that their original plaintext password can only be retrieved by brute-forcing the hash, which protects them only against reuse of the password on different sites. So on consideration, it will probably lead more to a false sense of security than an actual increase in security, yes. It no longer seems like a good idea to me. On Thu, Jun 16, 2011 at 7:28 PM, Sean Connelly s...@pbwhere.com wrote: This strikes me as abnormal; I'm not aware of the browser injecting form values for any other functionality. However, one benefit of this method is that a developer can create a JavaScript file to drop in to pages that will perform hashing for legacy browsers. The JavaScript could check to see if the browser performs hashing, and if not, add listeners on all form submissions. It could hash the password fields prior to submission, and inject the the synthesized form value. This would provide a path for legacy support. Side point: there are some existing cases where magic form values are injected. input type=image submits .x and .y values, for instance. The disadvantage to this approach is that, years from now, the default may be compromised (like md5). Another side point: MD5 is actually not compromised for the purposes of password storage. There are collision attacks, but no preimage attacks. Even MD4, which has had a working collision attack since 1995, still has nothing more than a theoretical preimage attack. So this isn't a huge worry in practice. Collision attacks aren't relevant to our use-case. (But don't use MD5 for things like certificate signing where collision resistance is important!) Yes, the site should. In fact, the webmaster should be doing additional hashing on the server side. However, we can't control that. If the webmaster is clueless and just stores the data directly (which webmasters do in the real world, unfortunately), at the very least, this solution will improve security. Only in one very narrow case: it will prevent a passive network attacker or someone who compromises the database from learning the original plaintext password without brute-forcing the hash. It will not stop them from logging in as the user on the same site, only from logging in as the user on other sites. On the other hand, administrators would be likely to assume that because the passwords now look like gibberish, they must be secure, which is totally wrong. Proper use of server-side hashing will leak no info about passwords to an attacker at all without brute-forcing, and proper use of client+server-side hashing will leak no info about passwords to a passive network attacker without brute-forcing. Making it easy to do hashing badly will discourage people from doing it well. I've read some of the thread... Please keep in mind that my proposal is not a catch-all solution to password management. It is intended to solve one specific problem. It is intended to be incremental progress. The problem is it solves much less of the problem than hashing is supposed to solve, but to the uninitiated it looks the same as a real hashing scheme. It gives a false sense of security that probably outweighs any actual security benefit (which is very limited).
Re: [whatwg] Normalization of user selections
Since I've somehow managed to send from the wrong address again for
the third time in 48 hours, here's yet another resent mail, probably
to be followed by a fourth when I respond to Boris' response and Gmail
auto-selects my non-list address again for the from address instead of
my list address:
On Thu, Jun 16, 2011 at 3:09 PM, Ryosuke Niwa rn...@webkit.org wrote:
What if we had foob/bi/ibar?
Well, what's the use-case?
Yes, I think all selection modified by user should be normalized by default.
I'm talking more about programmatically set selection. I think we'll need
to preserve programmatically set selection ranges instead of always storing
normalized ranges.
Normalizing the selection even when the author sets it is helpful
because it prevents authoring mistakes. For instance, if the author
wants to put the cursor at the end of an element, they might just do
getSelection().collapse(el, el.childNodes.length). But if the element
happens to be pfoobr/p, that's not what the author wants: if the
user types, it will insert text on a new line, when the br actually
has no visual effect and the cursor should go before it. So it would
help authors if pfoobr{}/p were automatically normalized to
pfoo{}br/p.
(br handling in this sort of situation is an absolute nightmare,
incidentally. I handle the really common cases currently in my
algorithms, but anything trivially different like
pfoospanbr/span/p will cause tons of stuff to break. It's
on my todo list, but there's only so much I can do without writing
some explicit and complicated description based on the CSS box model .
. .)
Still, since IE and Gecko already don't normalize, and we now have two
WebKit people against normalizing (you and Roland -- although Ojan in
favor), it seems like not normalizing is the more plausible path.
However, I'd still like to normalize author-set selections somewhat.
At a minimum, for instance, we could guarantee that a selection's
boundary point is always in a Text or Element node that descends from
a Document. That would be a big simplification by itself. Does
anyone object to that?
On Thu, Jun 16, 2011 at 3:12 PM, Boris Zbarsky bzbar...@mit.edu wrote:
As an actual user of editors, by the way, the #1 thing that pisses me off
about wysiwyg editors is precisely having situations like the one above and
wanting to be able to make the text be bfoo/borbar in some cases but
bfoopy/bbar in others. Wysisyg editors tend to be terrible at this
sort of thing. Is that something that's inevitable, or can we do better
here?
I don't know. I'm happy to hear suggestions.
On Thu, Jun 16, 2011 at 3:30 PM, Ojan Vafai o...@chromium.org wrote:
I agree it's unfortunate. I'm not sure we can do better though. The
advantage of Aryeh's suggested normalization is that it matches nearly every
popular word processor on the market, so is most likely to match user
expectations.
And all browser engines except Gecko now, too. I got it from your
writeup about contenteditable.
That said, I would like there to be declarative control over how the
normalization happens. For example, if I'm writing a custom widget, whether
typing should go inside or outside is different depending on the widget.
This is probably not the best API, but here's a concrete proposal to control
selection normalization at the end of an node.:
document.setSelectionNormalization(INSIDE/OUTSIDE, varargs of selectors);
Ouch, that looks very unpleasant. What's the exact use-case here?
On Fri, Jun 17, 2011 at 4:01 AM, Roland Steiner
rolandstei...@google.com wrote:
FWIW, I'm with Ryosuke on this one - NOT preserving programmatically set
selections seems very dangerous to me, esp. if it's just for the sake of
making it easier on the implementors. That way, neither the user NOR the
programmer has complete control over what is happening in detail.
As I note above, there are benefits to authors too -- we can avert
some types of mistakes. An explicit normalize() method as Ryosuke
suggests would only help authors who actually use it. But as I said,
given feedback so far, it looks like I'll be going for only minimal
normalization of author-set selections.
Exactly my thoughts. It's unfortunate that whether 2 different positions in
the DOM correspond to the same visual position cannot be determined by
looking at the DOM only - for example, there may be margins or even
auto-generated content around elements, that *do* neatly separate them.
Yeah, it's really depressing how huge and elaborate the CSS dependency
would have to be to fully account for all this sort of stuff.
Realistically, I think the spec is going to have to be defined in
terms of the DOM with only minimal CSS interaction -- although of
course it needs some -- and we'll have to accept that there will be
failures in corner cases. I don't want to have to go down the path of
talking about things like containing blocks and so on. If nothing
else, a JavaScript test implementation would be
Re: [whatwg] Selectors within style scoped
On Thu, Jun 16, 2011 at 1:40 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: As a web developer, I agree - my intuitive understanding of @scoped is that it makes matching *start* at the scoped element. That's what scoped means. The other meaning is more like a filter. Me too. I think it should be changed to work this way. The current way is confusing. FWIW, I also think that querySelector got this wrong. It should have scoped by default, and then possibly also offered an option to filter based on an element. I didn't think about that. If querySelector already does it this way, that's an argument for consistency, but I'm not sure it's very strong.
