[Webkit-unassigned] [Bug 31115] [Qt] QWebFrame::setHtml() should be removed

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=31115


Simon Hausmann <hausmann at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1




--- Comment #2 from Simon Hausmann <hausmann at webkit.org>  2009-11-21 00:56:35 PST ---
While I agree that setHtml() may not be a very "pure" function to have (give
the XHTML relation you mentioned for example), I still think it is a good thing
to have.

* The function is consistent with the rest of Qt (QTextEdit::setHtml,
QTextDocument::setHtml, QGraphicsTextItem::setHtml). Qt developers love the
fact that our API is consistent. The unspoken guideline is that an experienced
Qt developer shouldn't have to read the documentation of a class in order to
use it. That is why completely different classes like QTabBar, QComboBox or
QListWidget have a count() function. They're not called numTabs(), numItems()
or numListItems(), which would be a slightly tighter name. Instead they share
the same name so that the API remains concise.

* setHtml() is also very convenient. We say that with the Qt API common things
should be easy and special tasks should be possible. Populating a widget to
render web content with a given string of HTML falls clearly into the former
category. It is less error prone than calling setContent(htmlString,
"text/htlm"). Oh, oops, that should've been "text/html", but I only found out
at run-time because my text didn't show :)

* To satisfy the use-case of a more advanced task we added setContent(), which
is harder to use but also more flexible.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.