[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [RFC] filter redesign
From:       Nicolas Goutte <nicog () snafu ! de>
Date:       2001-09-13 20:52:47
[Download RAW message or body]

On Thursday, 13. September 2001 13:41, Vadim Plessky wrote:
> On Wednesday 12 September 2001 19:36, Nicolas Goutte wrote:
> |   On Tuesday, 11. September 2001 14:45, Vadim Plessky wrote:
> |   > I was wondering for some time why HTML exported by KWord, always was
> |   > using <P> ... </P> for every paragraph.
> |
> |   Because a paragraph is a <p> element in HTML!
>
> For sure :-)
> And support for it is some kind of *legacy support*.

I am sorry, but I DO care about legacy! I am sure that somebody will one day 
put on the Internet a HTML file created by KWord's HTML export filter. And I 
would like that visitors of that site would be able to read at least the 
text, whatever user agent they use, not just if they use the lastest browsers 
around.

And who tells you that the user agent will be a visual one. KWord's HTML 
export filter cannot give information for non-visual user agents, as KWord 
itself is visual-centered. So any reader (rendering to speech), braille 
display and so on can only rely on HTML tags. Using <div> and <span> is good, 
but abusing them is very bad!

> Web designers who still want to support Netscape 4.x (and MS IE 4.x),
> create a lot of netsted tables with 1pixel-size transparent GIFs, etc.
> Web designers who don't care about Netscape anymore (and that's majority),
> use DIV and SPAN everywhere. Hopefully, latest Mozilla build can handle
> this.

Mozilla is not an excuse. The note at the end of section 5.8 of the CSS2 
Specification does explicitely discourage to do things like that.

Additionally W3C ( http://www.w3c.org ) does still uses <p> in their 
specifications (I mean in the HTML files themselves.) And if I follow 
someone, it is the people who makes the (X)HTML specifications, not Mozilla.

>
> IMO DIV is much more modern technics than *old* P and tables.
> Note that you can even have scrollbar in fixed-size DIV element if context
> doesn't fit completely into it! :))
> // not sure wether Konq supports it, though.
>
> Major disadvantage of using P is that P *always* breaks line, and starts
> new block. So, if you want to have two paragraphs following each other -
> there is no, basically, a way to do this with P tag (except overriding CSS
> style with !importnat instruction and disbaling breaking)

From what I know, KWord always have a line break between paragraphs, so where 
is the problem? And if KWord would support something like suppressing the 
line break, then it is special case, that could be handle through CSS.

We are here creating a (X)HTML + CSS2 file, not a (generic) XML + CSS2 file.

> With SPAN, you can do it easily.
>
> Another problem is putting image.
> There is no problem to put an image inside DIV, but it's not very clear
> *how* <P> will behave if you placed picture inside.
> Sorry it may sound a little bit OT for KWord/KPresenter itself, it's more
> KHTML/Konq related, but it seems there is some kind of misunderstanding
> what should be <P> used for.

I am sorry, but I think that you do not have understood the concept of 
document structure, for what SGML was created (and from which HTML is 
derived.) HTML gives the structure, CSS how to display. *Both* are important!

>
> IMPORTANT NOTE:
> anyway, when you export image to HTML (either as IMG or as OBJECT of Image
> MIMEtype), you need to place it in some *bounding* structure.
> If you placed just in <BOFY>, following some paragraph, you can get
> unexpected results. I was comparing MS IE, NN 4.76, Mozilla 0.9 and Konq,
> and found that results will be pretty inconsistent.
> Options you have:
> * classic (n TABLE, for NN 4.7 compatibility)
> * in DIV / SPAN, a-la MS IE - but now it is W3C - compliant!
> * using CSS (CSS2) formatting - sound good, but who will render it
> correctly? While I personally would like to back last (3rd) option, I think
> second one (DIV/SPAN) is more practical.

However, the second solution is a catastrophe for non-visual user agents! 
With <table>, a non-visual user agent knows that a table is coming and can 
handle it correctly (for example for a reader with a different speech for 
column titles.)

>
> // oh, eys, you can use IFRAME as well, and insert IMG into complimentary
> frame (html), but is seems to me a little bit overhead.
>
> |   > While at a first glance it seems logical, almost for every paragraph
> |   > you redefine style (font size, color, font name, etc.)
> |   > It's much more convinient to use DIV, instead of <P>, for every
> |   > paragraph.
> |
> |   The HTM 4.01 Specification defines <div> as "generic language/style
> |   container", that is not a paragraph!
>
> Yes.
> That's why it's rather difficult to insert one paragraph in another, if you
> use P.

Sorry, I have really to ask: but why do you want nested paragraphs? What 
advantages does this bring to you?

> And there is no problem with it if you use DIV and SPAN.
>
> |   > Then you don't have such limitations.
> |   >
> |   > At a moment, you just can't have nested paragraphs :-((
> |
> |   Since when does KWord support nested paragraphs? Or do I have missed
> |   something?
>
> I forgot to file wishlist for it. :-))
> I supposed it's expected in future versions, and was just not implemented
> in KWord 1.1.
> Are there any problems with nested paragraphs in QRT from QT3?
> May be, we should bugreport TrollTech now, than?
>
> |   > BTW: I found serious inconsistance when view exported from KWord HTML
> |   > in different browsers.
> |   > Reason: KHTML uses to much space *before* and *after* <P> (about 1em
> |   > in each case), while Mozilla - only half of it.
> |
> |   That will change when the space before and after the paragraph will be
> |   exported as CSS too. But then I am sure that I will have complaints
> | like: "But why there is no space between paragraphs in exported HTML."
>
> I think default settings of KWord should be exported.
> There is default setting for before and after paragraph space, right?
> So you can export them in HTML.
>
> |   > So IMO it's not good to count *default* behavior/style for P tag,
> |   > it's better to define it each time (or to have extra option for this)
> |
> |   Sure, that is called style in KWord and class in CSS but I was trying
> | to make a library for KWord export filters before finsih it. But however,
> | I have the feeling that nobody cares anymore that I write this library
> | when I read this thread.
>
> No-no, I care!...
> Sorry I was not very active on list recently, August was rather mixed for
> me and I decided to make some break, but I follow the list ...
> Hope to participate more actively soon!
>
> |   Have a nice day/evening/night!
>
> Take care!

Have a nice day/evening/night!
_______________________________________________
Koffice-devel mailing list
Koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]