17241 2012-05-30 05:02:42 +0000 Editing API spec needs to be aware of PRE contents 2013-02-04 02:14:08 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - HTML Editing APIs unspecified All All NEW P2 normal --- 1 rniwa ayg mike public-webapps sideshowbarker+html-editing-api oldest_to_newest 68295 0 rniwa 2012-05-30 05:02:42 +0000 It appears that the current specification doesn't do anything special for PRE elements. It needs to be fully aware of PRE elements, and treat each line in PRE as a separate paragraph. 68395 1 ayg 2012-05-31 11:32:46 +0000 Can you give some examples of what should behave differently? It is aware of CSS 'white-space' values, and in some places treats 'pre'/'pre-wrap'/etc. differently (at least for whitespace handling). insertParagraph also treats address/listing/pre differently from other block elements. 68436 2 1139 rniwa 2012-05-31 16:52:19 +0000 Created attachment 1139 demo (In reply to comment #1) > Can you give some examples of what should behave differently? It is aware of > CSS 'white-space' values, and in some places treats 'pre'/'pre-wrap'/etc. > differently (at least for whitespace handling). insertParagraph also treats > address/listing/pre differently from other block elements. Sure. As you point out, white-space: pre, white-space: pre-wrap, etc... should be treated like pre here but, indent command for example should treat each line in pre so if we executed indent command with the following selection: <pre> [hello] world </pre> We should get <blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"> <pre>hello</pre> </blockquote> <pre>world</pre> or <pre> <blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"> hello </blockquote> world </pre> Gecko appears to indent the whole block (hello & world) but that doesn't seem right from user's perspective because there's no visual difference between the above markup and hello world with which Gecko gladly indents "hello". 68495 3 ayg 2012-06-01 11:19:26 +0000 Good point. I was actually thinking about whether we want that behavior for , though. If I use Shift-Enter to get "foo bar", should that really be treated as two blocks instead of one? It is in browsers, but I'm not sure that makes sense. "<li>foo bar</li>" is treated as one block, but "foo bar" is not . . . I don't disagree, though. As long as we have this behavior for , we should have it for <pre>. However, the spec and Gecko currently don't actually produce literal linebreaks in <pre>: hitting Enter inside <pre> generates . And WebKit splits it into multiple <pre>s, like or <div>. So the only way you'd get literal \n in <pre> is if the preexisting HTML had it, right? This strikes me as a low-priority use-case. 68525 4 rniwa 2012-06-01 18:11:17 +0000 (In reply to comment #3) > Good point. I was actually thinking about whether we want that behavior for > , though. If I use Shift-Enter to get "foo bar", should that > really be treated as two blocks instead of one? I think it should be. As far as naive users are concerned, "p" is a "br" with extra margins. > It is in browsers, but I'm not > sure that makes sense. "<li>foo bar</li>" is treated as one block, but > "foo bar" is not . . . In the case of a list item, there is a bullet point (with default css), so it probably makes senes to treat each bullet pointed item as a single entity. > I don't disagree, though. As long as we have this behavior for , we should > have it for <pre>. However, the spec and Gecko currently don't actually > produce literal linebreaks in <pre>: hitting Enter inside <pre> generates . > And WebKit splits it into multiple <pre>s, like or <div>. So the only way > you'd get literal \n in <pre> is if the preexisting HTML had it, right? This > strikes me as a low-priority use-case. I think I would be fine if you just inserted at wherever \n appears as some sort of a pre-processing step. Once you support treating-br-as-paragraph-separator (misnomer but can't think of a better phrase), then it should just work regardless of whether we're in pre or not. 1139 2012-05-31 16:52:19 +0000 2012-05-31 16:52:19 +0000 demo indent.html text/html 271 rniwa PCFET0NUWVBFPgo8aHRtbD4KPGRpdiBjb250ZW50ZWRpdGFibGU+CjxwcmU+aGVsbG8Kd29ybGQ8 L3ByZT4KPC9kaXY+CjxzY3JpcHQ+Cgp2YXIgcHJlID0gZG9jdW1lbnQucXVlcnlTZWxlY3Rvcign cHJlJyk7CmdldFNlbGVjdGlvbigpLmNvbGxhcHNlKHByZS5maXJzdENoaWxkLCAwKTsKZ2V0U2Vs ZWN0aW9uKCkuZXh0ZW5kKHByZS5maXJzdENoaWxkLCA1KTsKZG9jdW1lbnQuZXhlY0NvbW1hbmQo J2luZGVudCcsIGZhbHNlLCBudWxsKTsKCjwvc2NyaXB0Pgo8L2h0bWw+Cg==