Re: [whatwg] Proposal: content-style attribute for contenteditable elements
Am 19.05.2011 20:39 schrieb Aryeh Gregor: On Tue, May 17, 2011 at 4:09 AM, Markus Ernst wrote: While discussing about contenteditable elements, the WYSIWYG aspect was mentioned. For real WYSIWYG in a text editor of a CMS, Blog, Forum or whatever, it would be necessary for the contents of the contenteditable element to: - Disable the styles of the surrounding page - Enable the styles of the target page Commonly these are the same, or close to it. If the contenteditable region is part of the UI of a content management system, they are likely to be completely different. In the cases where the styles are really different, it should be fine to require authors to use an iframe. Ok, I see this point.
Re: [whatwg] Proposal: content-style attribute for contenteditable elements
On Tue, May 17, 2011 at 4:09 AM, Markus Ernst wrote: > While discussing about contenteditable elements, the WYSIWYG aspect was > mentioned. For real WYSIWYG in a text editor of a CMS, Blog, Forum or > whatever, it would be necessary for the contents of the contenteditable > element to: > - Disable the styles of the surrounding page > - Enable the styles of the target page Commonly these are the same, or close to it. Just serve the same stylesheet and apply the same classes or whatever to the contenteditable region as to the final //etc. In the cases where the styles are really different, it should be fine to require authors to use an iframe. > Rationale: > - In today's iframe-based online rich text editors, it is common to apply > the styles of the target page of the edited text to the source document of > the iframe. This is not possible in a . > - For many use cases, such as forum and blog entries, or non-fullpage > oriented web content management systems, is easier to > implement than iframe-based editors. The only downside is the WYSIWYG issue. It's not much harder to use an . You can just set it up with no src and use JavaScript to set .contentDocument.body to whatever you'd have set your contenteditable element to. You don't have to make it actually load a separate page. (Although browsers might not save the contents over browser crash/etc. if script sets the contents when the page loads. You could work around it in a few lines by saving to localStorage or sessionStorage regularly, which is a handy feature anyway.) On Tue, May 17, 2011 at 11:23 AM, Tab Atkins Jr. wrote: > Why not just use an with a contenteditable inside the linked > page? This also gives you the ability to link in arbitrary CSS and be > shielded from the outside page's CSS, and as long as the linked page > is same-origin, you can still fiddle with it from script in the outer > page. If you're using an iframe, it makes more sense to use designMode than contenteditable.
Re: [whatwg] Proposal: content-style attribute for contenteditable elements
On 5/17/11 2:40 PM, Tab Atkins Jr. wrote: Doesn't really matter to me; either seems sensical. :root has the benefit of existing. ^_^ :scope has the benefit of making more sense (and happens to exist in my tree, is used in the proposed selectors API, etc). -Boris
Re: [whatwg] Proposal: content-style attribute for contenteditable elements
On Tue, May 17, 2011 at 11:05 AM, Boris Zbarsky wrote: > On 5/17/11 11:23 AM, Tab Atkins Jr. wrote: >> On Tue, May 17, 2011 at 1:09 AM, Markus Ernst wrote: >>> Special cases: >>> - If the linked CSS document contains declarations for the body element, >>> they are applied to the contenteditable element itself. (This could be >>> necessary in case of light text on dark backgrounds, where you want to >>> apply >>> the background to the contenteditable area.) >> >> It would be cleaner to simply say that the contenteditable element >> matches the :root pseudoclass in the linked sheet. > > :root, or :scope? Doesn't really matter to me; either seems sensical. :root has the benefit of existing. ^_^ ~TJ
Re: [whatwg] Proposal: content-style attribute for contenteditable elements
On 5/17/11 11:23 AM, Tab Atkins Jr. wrote: On Tue, May 17, 2011 at 1:09 AM, Markus Ernst wrote: Special cases: - If the linked CSS document contains declarations for the body element, they are applied to the contenteditable element itself. (This could be necessary in case of light text on dark backgrounds, where you want to apply the background to the contenteditable area.) It would be cleaner to simply say that the contenteditable element matches the :root pseudoclass in the linked sheet. :root, or :scope? -Boris
Re: [whatwg] Proposal: content-style attribute for contenteditable elements
On Tue, May 17, 2011 at 1:09 AM, Markus Ernst wrote: > Special cases: > - If the linked CSS document contains declarations for the body element, > they are applied to the contenteditable element itself. (This could be > necessary in case of light text on dark backgrounds, where you want to apply > the background to the contenteditable area.) It would be cleaner to simply say that the contenteditable element matches the :root pseudoclass in the linked sheet. > Rationale: > - In today's iframe-based online rich text editors, it is common to apply > the styles of the target page of the edited text to the source document of > the iframe. This is not possible in a . > - For many use cases, such as forum and blog entries, or non-fullpage > oriented web content management systems, is easier to > implement than iframe-based editors. The only downside is the WYSIWYG issue. Why not just use an with a contenteditable inside the linked page? This also gives you the ability to link in arbitrary CSS and be shielded from the outside page's CSS, and as long as the linked page is same-origin, you can still fiddle with it from script in the outer page. ~TJ
[whatwg] Proposal: content-style attribute for contenteditable elements
Hello While discussing about contenteditable elements, the WYSIWYG aspect was mentioned. For real WYSIWYG in a text editor of a CMS, Blog, Forum or whatever, it would be necessary for the contents of the contenteditable element to: - Disable the styles of the surrounding page - Enable the styles of the target page This could be solved with a @content-style attribute which takes a URL pointing to an external stylesheet document. If the attribute is present, all styles of the surrounding page are ignored, and the styles of the linked CSS document are applied to the content of the element. Special cases: - If the linked CSS document contains declarations for the body element, they are applied to the contenteditable element itself. (This could be necessary in case of light text on dark backgrounds, where you want to apply the background to the contenteditable area.) - If there are conflicts between body element styles in the linked stylesheet and the styles of the contenteditable element in the surrounding page, the latter win. (This is necessary to keep the dimensions of the input UI, if an author links the whole CSS of the target page.) Rationale: - In today's iframe-based online rich text editors, it is common to apply the styles of the target page of the edited text to the source document of the iframe. This is not possible in a . - For many use cases, such as forum and blog entries, or non-fullpage oriented web content management systems, is easier to implement than iframe-based editors. The only downside is the WYSIWYG issue. I'd be happy to read some comments on this idea!
