Server Notice:

hide

Public Pad Version 2598 Saved Aug 30, 2011

 
Day 1
 
Aryeh's editing spec
  • Might be hard to change the behavior of browser to match the spec in some cases (e.g. backColor on Gecko)
  • Need to way to measure the consistency between the reference  implementation and browsers - test suite, maybe let reference impl. run  WebKit/Gecko's test suites to see how much it passes?
  • Need to handle nested editability, SVG, MathML (we should at least not garble SVG & MathML)
  • It would be good if implementations could converge gradually on parts of the spec which don't break web compatibility too badly
Mutation events
  • Need more editor use cases (and also non-editor use cases)
  • Do not add equivalent thing on after editing command event
  • Do not evoke observers after each editing command; we should de-couple editing and mutation notifications
  • Would like to address most (editing) use cases by after editing command event
UndoManager
  • The goal here is to provide a simple API which doesn't try too hard to prevent the authors from doing stupid things
  • Each UndoManager should be non-reentering.  For example, while a transaction is in progress in one UndoManager, another transaction should not be started on the same UndoManager.
  • We mostly ignore the weird scenarios which could happen with nested UndoManagers.
  • <del>Remove  proper sequence of managed transactions, just say that DOM states must  be same</del> <ins>This won't work in the case where we have  an editor and canvas/SVG/MathML /etc... because the latter won't  necessarily have the same DOM state.</ins>
  • undoscope: managed transactions shouldn't revert any changes outside of undoscope
  • UndoManager should have both manualTrasact & managedTrasact instead of implicitly determining the kind
  • Each execCommand call, if there is no current transaction, will start a new one which will span both the before and after events firing
  • Add TransactionEvent, Undo, & Redo events; just needs to be spec-ed.  One use case for TransactionEvent could be enabling the Undo/Redo buttons in the UI of the webapp.
  • TransactionEvent is not necessarily related to "after editing action" events, since a single transaction might include multiple execCommand calls
Editing command events
  • before editing command:
  • Should let scripts replace browser's implementation by preventDefault-ing the event
  • Should have command name and value
  • Maybe normalize value so that scripts don't have to parse color, fontsize, etc...?
  • Probably doesn't need other properties
  • Canceling the before event will prevent the after event from firing
  • May want to do some sanity checks before firing the "before" event, but shouldn't perform any command specific checks before firing this event, in case scripts want to change the behavior so much that the check would not make sense
  • after editing command:
  • fixup / cleanup / do extra stuff
  • need to know use cases - rniwa contacts editors
  • We prefer to add less properties at first, and add more as people come up with use cases
Selection API
  • Add Selection.clone
  • Add a way to create new "blank" Selection objects (document.createNewSelection/window.createNewSelection -- bikeshedding!)
  • Get rid of multi-range selection - ehsan will (hopefully) hide it from scripts.  need to discuss this with other Gecko folks
  • Maybe invest time on how to better support table editing (future project)
 
Day 2
 
Future ideas:
  • IME
  • The IME UI shown by browsers is currently not accessible to web content
  • The IME UI is usually provided by the OS
  • Baidu implements its own IME engine, but most websites want the UI customization
  • ehsan will put Masayuke in touch with Ryosuke
  • Keyboard events interop
  • We know that there are problems with browsers not sending the correct keyCode under some keyboard layouts, but it's not the area of expertise of any of us
  • The Cmd/Opt/Ctrl keys on Mac are a pain since they don't have a real equivalent on Windows/Linux
  • Keyboard shortcuts
  • Ctrl+A/B/I/U/Z/shift-Z(or Y)/C/X/V are well defined so we should support them
  • We want a platform independent way of defining shortcut keys like accesskey
  • We might want to add a for attribute on command elements which point to the IDs of the contenteditable element(s) to which the command should be applied
  • We might want to let the author to declare key combination hints for accesskey activation, like "accel", "ctrl", "shift", "alt", etc
  • ehsan thinks that we should really not require authors to handle key events for keyboard shortcuts, and others seem to agree!
  • Privacy should be kept in mind if we decide to expose which key combination was really picked by the UA
  • Spell checking
  • There may be privacy implications if the web app can detect which words are marked as misspelled
  • Exposing some of the base editing algorithms as commands
  • Example: exposing the "wrap" algorithm
  • Do we want to expose really complicated algorithms which take ~10 callback functions as parameters?
  • CKEditor wants this!
  • We should follow up with the web editor widget authors to see what kinds of stuff they would want us to expose.  Aryeh is going to talk to them.
  • This is all future work, we should wait for the spec to stabilize before jumping into this
  • Accessibility concerns
  • Keyboard/caret navigations needs to be specified at some point
  • There might be cases which need to be platform specific, but we should try to be as specific as possible
  • Resizing and table editing UI
  • Gecko tries and fails, webkit doesn't try to provide any UI
  • We think that we may be able to hijack the CSS resize property
  • We may want to provide resizing handles as the UI for images, tables, block elements, etc
  • Table editing UI needs to be a future project, definitely wanted, but too big to tackle at this point
 
  • Collaborative editing
  • Annie gave an overview on how collaborative editing works
  • We want semantic information on events about what the user wants to do (before/after events which we discussed go a long way towards this)
  • We want selection change events (possibly cancellable events)
  • Authors want semantic information on how the selection is going to change, for example, extending a selection by one word forward
  • Google docs gave up on contentEditable because of implementation differences between UAs, and also because of their custom layout requirements
  • Aryeh and ehsan think that p should be the default paragraph element, Ryosuke doesn't agree (or at least other WebKit people don't agree; Ryosuke will talk to them)
  • Having a changeTag command of some sort would be extremely useful for the div/p or b/strong case
  • The transaction logs which can be captured from transaction/undo/redo events might help with the data model problem and also the diffing problem
  • The Mutation Notification events may also help here
  • Ryosuke mentioned the idea of adding a "marker" to the mutation notifications to denote the transaction boundaries, but it seems like this is something that we should support only when somebody comes up with a concrete use case for.
 
  • Clipboard API
  • User initiated clipboard operations shoud probably be supported
  • Putting data on the clipboard might be annoying, or might be dangerous if they put cmdline data and convnce the user to paste into a terminal
  • Pasting data from the clipboard needs UA level protections
  • sicking thinks that we're going to have a bit more flexibility with security models going forward, like granting permission to installed web apps or something
  • we're going to escalate this to the UX teams at Mozilla and Google
  • discussed what should happen if we want to disable pasting of things like absolutely positioned content
  • we think that the way forward would be to let the content clean up the pasted fragment in the "onaftereditaction" event, at which point it actually has access to things like resolved styles, etc.
 
  • Implementation
  • ehsan and ryosuke discussed how gecko and webkit implementations work
  • we discussed some ideas about sharing tests between gecko and webkit (and maybe other browsers)