On Wednesday, October 12, 2011 11:31:56 AM Jos van den Oever wrote: > On Wednesday, October 12, 2011 10:35:40 AM Sebastian Sauer wrote: > > On 09/30/2011 07:04 PM, Jos van den Oever wrote: > > > On Friday, September 30, 2011 18:48:59 PM Sebastian Sauer wrote: > > >> On 09/30/2011 06:17 PM, Boudewijn Rempt wrote: > > >>>> Anything you do in such development is constrained by WAC unless you > > >>>> agree to break compatibility and inject binary lib - then you'd have > > >>>> to deploy it to other systems too (but the why to skip native Qt > > >>>> programs?) > > >>> > > >>> I don't agree. I think it's perfectly possible to write a > > >>> full-featured office suite in html + javascript. Google has already > > >>> done that. > > >> > > >> google docs is not even close to be a full-featured office suite. It's > > >> an extended text-editor > > >> on top of a relational db. The gdata-API is insufficient for anything > > >> more complex. But then > > >> that is also an advantage. They don't try to be feature-complete with > > >> MSOffice/OpenOffice/Calligra > > >> but only offer an online (and since some time even offline) richtext > > >> editor/calculator/presenter. > > >> > > >> But yes, I think that it would be possible too :-) > > > > > > There are things that are simply impossible or very hard even in HTML5. > > > For exmple consider positioning of draw:frame in a brower. The anchor > > > can be relative to paragraph, to character or to page. This distinction > > > is not so easy to do in CSS. I give this example since I've studied > > > that recently. > > > > I did study WebOdf a bit but now I wonder why only CSS? I mean why > > not some Javscript-magic that does the positioning? > > This is done partially. Some thing cannot be solved with only css. In these > cases, a custom attribute is added, a position calculated with css and this > is then used. It it not possible to do positioning directly on non-html > elements in all browsers; one needs to go via CSS. But the logic is still > done with javascript. > > > > What the best solution is, I cannot tell. I think that HTML5 layout > > > will become more advanced and that webodf will benefit from that. > > > > That would be HTML6 or 5.1 then. Taken the current speed HTML > > and the browsers develop into account that's perfect possible. > > No, it would be a newer CSS version, HTML is irrelevant. But also in CSS > there is quite some movement, e.g. > http://www.w3.org/TR/css3-multicol/ > http://www.w3.org/TR/css3-text/ > http://www.w3.org/TR/css3-page/ and http://dev.w3.org/csswg/css3-exclusions/ http://labs.adobe.com/technologies/cssregions/ These really make ODF much more mappable to HTML + CSS by introducing advanced wrapping and pagination and frames. This leaves the problem of tab stops though. Some older proposal is not implemented, as far as i know: http://www.w3.org/People/howcome/t/970224HTMLERB-CSS/WD-tabs-970117.html
Cheers, Jos _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
