[Kde-pim] user css controlled mail appereance... reload.

Thu Nov 13 22:36:24 GMT 2008

Hi everyone.

1. off, apologies for the delay and thread breaking - i did (again) what i 
should not do and posted to a list i'm not subscribed to, so:
--- please keep me in cc for the moment, thanks.

2. i hope to have a 1st patch after this WE

now on topic:

> you would handle mails that does not come with all the header data we
> [...]
> template into several files. Or the (one) template file would have some
> extra structure with markers that you would have to parse...I think
> this is possible, although not that nice.
my (html inclusion has yet not been finished, but WE is near...) approach is 
pretty simple:
---------------
dynamic content is inserted via the 
object id and css ":after"
(i.e. kmail has a little power even after the userstyle is applied)

att "display:none;" is in case also applied to objects != {subject, sender, 
receiver} where i just add some def. content ("No Subject")
so a (incomplete) <html> part could look like:

<h1 id="subject"/>
<div id="sender"><span id="fromLabel"/></div>
<div id="CC"><span id="ccLabel"/></div>

and kmail (after the screen and user css have been applied) does some:

'#subject:after { content:\"message->subject().isEmpty() ? i18n("NoSubject") : 
strToHtml( message->subject() )\"; }'
...
if (message->cc().isEmpty())
   #cc { display:none; }
else ...

@Ingo:
i intended to extend kmail/headerstyle here. if this should be shared between 
kmail, kontact, akregator: is this still the right place or is there another 
central hook?

> Using only CSS templates (the HTML would be some divs/spans in the c++ code) 
has some limitations?
yes.

> At least I wasn't successful in trying to change the order of the header
> elements (say, first showing the from data, below it the subject and
> then the to-part).
it "is" "possible" - if you can assume (or css force) no line breaks, you know 
each elements height, and play with position:relative; but this is a nasty 
hack and will sooner or later break in one or another way. (i.e. you'l have 
overflow trouble or your geometry assumptions don't hold)

> Maybe that are just my css skills that are limited ;)
no. maybe yes. but not in this point... =D

> Well, actually I changed the order with css (using ...
... notanswerbeforereadingnotanswerbeforereadingdonothandlemailsserially ...

> But if you say it's possible to change the order of the
> elements (for long lines/texts, for increased font size etc...) just by
> using css, that would be just cool :)
nope. dom is js territory. and relative repositioning will fail w/ linebreaks

> change everything just by css? What about some javascript stuff?
NO JS IN MY MAILS. (sorry for shouting. the whole custom styling thing is 
mainly to convince ppl. to /not/ use html mails, please... Please... 
PLEASE!!!)

> As one metion in the mailing list before, it would be cool if we could
> collapse the header to a one-liner like in thunderbird and things like
kmail could add this as js internally, but wait - i forgot:
NO JS IN MY MAILS! ;-P

however, there seems  to be an internal protocol (used with the quotemarks in 
objectparser.cpp, kmail:levelquote?x) i assume this could easily be extended 
to (un)collapse the header (to the subject or whatever)

and what precisely is this "thunderbird" then?
why can relatively old cars handle mails? %-)
;-)

> My next idea was to use a more generic method for creating the headers.
> Imagine KMail creates a xml file in memory for the header of the mail
> [...]
i'm with Ingo (...oh, and you, i just see - donotprocessmailsserially...) 
here: "smells overheaded"

(xml/xsl is really mighty generic and though splitting content and style 
beyond html/css does anyway is certainly clean, but as long as it's kmail 
internal... well i guess my box doesn't care much about strcuture in it's RAM 
mess)

in the end you'd... (s.above) - yeah. you know what you did in the end, and 
we're (ok, at least /i am/) just interested in a very small subset of that 
power... (but i assume any ng mail protocol will use xml...)

> (since we can use html/css/javascript and what not in the *.xsl file)
oh, and before i forget: NO JS PROCESSING IN MY MAILS: NEVER! ;-P
(i'd change back to mutt, then)

Regards,
Thomas
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/