On Wed, 11 Jan 2012 16:39:48 +0100, Aryeh Gregor <a...@aryeh.name> wrote:
On Tue, Jan 10, 2012 at 3:50 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
p has default margins. That alone is enough for us not to adopt p as
the default paragraph separator.
On Wed, Jan 11, 2012 at 5:15 AM, Simon Pieters <sim...@opera.com> wrote:
Sure, but some apps like to send their stuff in HTML email to clients
that
don't support styling, or some such.
I used to think that this was a strong argument, but then I realized
<blockquote> and <ol> and <ul> have default margins too. So if you
want it to look right, you'll have to use a stylesheet. Also, it's
worth pointing out that recent versions of Word have margins by
default when you hit Enter.
But Simon makes a good point: for the e-mail use-case, styling might
not be available. So this is a decent reason to support <div>.
Also, unfortunately, there are many legacy
contents that rely on the fact webkit uses div as the paragraph
separator so
we need a global or per editing-host switch regardless.
This is also a good reason -- it lets preexisting apps that expect
<div> opt into that behavior in new browsers, instead of being
rewritten to support <p>.
Okay, so what API should we use? I'd really prefer this be
per-editing host. In which case, how about we make it a content
attribute on the editing host? It can be a DOMSettableTokenList.
Maybe something like
<div editoptions="tab-indent">
where the attribute is a whitespace-separated list of tokens. To
start with, we can maybe have tab-indent (hitting Tab indents) and
div-separator (hitting Enter produces div). Does this sound like a
good approach? If so, what should we call the attribute?
Currently the editing options available, other than enabling and disabling
contenteditable, use the execCommand API. I don't see why we should switch
to attributes for new editing options. To make editing options per editing
host, I prefer this proposal:
[[
Ojan suggested in the other thread that we instead allow calling
execCommand() on Element, and have the result restricted to that
Element. That solves the global-flags problem too, and doesn't
require new attributes. So you'd do
div.execCommand("tabindent", false, "true");
or whatever. Someone could still call
document.execCommand("tabindent", false, "false"), but that would be
overridden if it was called on the editing host. I filed a bug on it:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15522
Does that sound good too?
]]
And should
it imply contenteditable=true, or should the author have to specify
that separately?
The latter IMHO.
Also: are there any good use-cases for <br>?
I still haven't seen any.
Allowing <div> instead
of <p> adds basically no extra complexity, but allowing <br> would
make things significantly more complicated.
On Wed, 11 Jan 2012 21:15:18 +0100, Ryosuke Niwa <rn...@webkit.org> wrote:
> Should enter behave like shift+enter when br is the default
> paragraph separator?
Default paragraph separators are used in a couple of other places too,
so it would be a little more work than that.
Indeed, e.g. shift+enter doesn't break out of lists, so it's not
equivalent. Making it equivalent would be adding some complexity.
But I just looked, and
it wouldn't be as bad as I thought. So this is doable if people have
any good use-cases.
Great.
So what's the use case? :-) If none are presented, I object to adding it
based on the Avoid Needless Complexity and Solve Real Problems design
principles.
--
Simon Pieters
Opera Software
