Bug 56623
| Summary: | Consider adding an execCommand to apply an arbitrary set of CSS styles. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Justin Garcia <justin.garcia> |
| Component: | HTML Editing | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ayg, leviw, rniwa |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | OS X 10.5 | ||
Justin Garcia
Consider adding an execCommand to apply an arbitrary set of CSS styles. It would be useful for testing at the very least.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Aryeh Gregor
This is extremely nontrivial in practice. CSS styles that don't behave in a very particular way need a whole bunch of special-casing to work properly with execCommand(). There's unique special-case code for every command in my spec except bold, fontName, and italic, I think. There are probably only one or two additional properties that would make any sense without special-cases, like font-variant.
We do definitely need to make execCommand() more extensible going forward, once the current implementation is settled down a bit more. But it's not likely to be a matter of just passing the name and value of a CSS property, more like the author will have to write a few callbacks.
Ryosuke Niwa
(In reply to comment #1)
> This is extremely nontrivial in practice. CSS styles that don't behave in a very particular way need a whole bunch of special-casing to work properly with execCommand(). There's unique special-case code for every command in my spec except bold, fontName, and italic, I think. There are probably only one or two additional properties that would make any sense without special-cases, like font-variant.
Agreed. Properties like float, display, position, etc... are extremely painful to deal with.
> We do definitely need to make execCommand() more extensible going forward, once the current implementation is settled down a bit more. But it's not likely to be a matter of just passing the name and value of a CSS property, more like the author will have to write a few callbacks.
I had a lengthly discussion with authors of CKEditor and TinyMCE about this, and it appears that we can provide some API to make their life easier by letting them wrap nodes, split tree, etc... so that authors can implement those features themselves but without having to re-implement all algorithms in your spec.
Aryeh Gregor
Yes, that's definitely the way forward. I want to see the spec become more stable/widely implemented before we expose any of the algorithms to authors, though, because until then I want the flexibility to refactor things if necessary. So for now I'm focusing on stabilization and cleanup, and once the spec is in better shape we can add some new methods.