[WebODF] RFC: Making OpApplyStyle and OpUpdateParagraphStyle more consistent

[Philip Peitsch]

On 27 July 2013 01:15, Friedrich W. H. Kossebau <friedrich at kogmbh.com>wrote:

> > > In matters of b), OpUpdateParagraphStyle has a payload
> "removedProperties"
> > > which stores the names of all attributes that should be removed. That
> was
> > > done like that instead of listing the attribute with value >null<,
> > > >undefined< or "" in the "setProperties" to express that is should be
> > > removed, because >null< and >undefined< might not exist in other
> > > languages and "" could be an actual valid value.
> > >
> > > Q: does it make sense to add something similar like
> "removedProperties" to
> > > OpApplyStyle? I guess it does.
> >
> > This concept doesn't really make any sense for direct formatting.
> >
> > For example:
> >
> > <p style="font-weight: bold"><span>hi</span> there!</p>
> >
> > I might accidentally think that to make the "hi" text non-bold, I should
> > OpApplyStyle with removedProperties =[font-weight]. This doesn't make any
> > real sense though, as the element I'm formatting (the styling of the
> span)
> > doesn't have a property to remove.
> >
> > If I remove it off the paragraph element, I'll incorrectly unbold "
> there!"
> > as well.
> >
> > The end user intent is never to remove formatting (with the exception of
> a
> > specific OpRemoveDirectFormatting option or similar). Rather, when they
> say
> > "unbold this", they really mean "make this range font-weight=normal".
>
> While I agree for what the user expects by his input via the UI, I was more
> thinking in op spec terms and of people doing some manipulations of the DOM
> based on algorithms, where they might want to be able to also remove
> properties, not just add/change.
>

I'm meaning the ambiguity of how a text property is removed seems
unsolvable.
If I give the instruction to have a text property removed from a block of
content
in a paragraph, does that mean crawl up the parent styles and clone with
this
setting removed? Or does it mean delete it off the parent styles directly?

Apart from the limited remove direct formatting case (which means delete all
auto-style references from the selection), I still don't know how you would
remove
a text-property. As in the above example, how do you figure out which
member in
the style hierarchy to remove the text-propery off of? It seems like an
extremely
murky feature, so personally I'd leave it out until someone finds the first
concrete
usecase to help us understand what the end goal is :-)


> > > For c) I wonder what the plans are for paragraph styling. There is no
> TODO
> > > or anything else mentioned. And I am only thinking of the op spec, not
> of
> > > the actual implementation how to execute this op.
> > >
> > > Q: Should the same op be used for direct paragraph styling? So should
> > > there
> > > be, like in OpUpdateParagraphStyle, another section
> "paragraphProperties",
> > > next to "textProperties"?
> >
> > I wrote OpApplyStyle to allow the possibility of that taking care of
> > paragraph and text properties if desired. But, I'm not particularly
> > attached to that approach.
>
> Okay, so would be possible to have also paragraph properties in the same
> way
> like in OpUpgradeParagraphStyle in theory. Just needs someone in practise
> to
> write the proper code :)
>

Depending on workload, I may have a crack at this at some point soon. Am I
correct in assuming this should have the same style-clone logic (i.e.,
create an
auto-style linked to the parent and override)? Alternatively, if someone
else wanted
to better understand that part of the code, this would be a wonderful
introduction
task... ^_^


> > I like OpApplyStyle's range-based operation. It makes translation from
> the
> > cursor easier, and the operation is still quite straightforward. But… I
> am
> > worried about whether inverse operations (i.e., proper undo) can be
> created
> > for range-based operations .
>
> Agreed. Same fate as OpRemoveText possibly...
>

I have some theories about Operations being able to generate their inverse
as they
process which might be able to help here. But... nothing proven or even
beyond the
thought experiment stage. I suspect that is an entirely other email chain
we'll
start at some point in time.


The landing MRs all look good! It even feels like we had a process &
discussion
around this change! Well done :D
-- 
Philip Peitsch
Mob: 0439 810 260
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open.nlnet.nl/pipermail/webodf/attachments/20130728/c9a532cf/attachment.html>