17723 - [HELP WANTED] Redesign OutputSinks

Status: VERIFIED WONTFIX

(Core :: DOM: Serializers, defect, P2)

Description

[Ben Bucksch (:BenB)]

HTMLToTXTSinkStream and related files are a mess. create class hierarchy. more
follows.

Comment 1

[Akkana Peck]

Ben and I were talking on IRC, and here's a sketch of what I was thinking at the
time:

We could start with nsOutputSink, which would have things like setting up the
unicode encoder and having Write() methods.

Then split into nsHTMLOutputSink and nsPlaintextOutputSink (ah, to get rid of
names like nsHTMLToTXTSinkStream.h !)

Then for example, nsPlaintextOutputSink could have nsUnformattedPlaintextSink
and nsFormattedPlaintextSink, and so forth.

The object of this is to have a cleaner hierarchy where we don't have all these
complicated output flags.  Unfortunately it's hard to do inheritance of
interfaces in the same way, so this might not help the user who's stuck going
through nsIDocumentEncoder, unless we create a zillion new interfaces.

Comment 2

[Ben Bucksch (:BenB)]

Class Hierarchy (names will change):
OutputSink
+--HTML
+--plain text
   +--unformatted
   +--formatted
      +--traditional
      +--format=flowed

OutoutSink is a stream converter (see bug #1775).

Comment 3

[Daniel Bratell]

I think this is a good thing in general, but note that the same input data can
have both parts that should be output formatted and parts that should be output
as if it were preformatted. That means that the same logic will have to be
duplicated which are a bad thing.

Comment 4

[Ben Bucksch (:BenB)]

Changing COmponent to Output and adding bug #16800 as dependency.

Comment 5

[Ben Bucksch (:BenB)]

Daniel's changes (bug #16398) have been checked in. I can't work, if I get no
information.

Comment 6

[Akkana Peck]

Setting milestone low because it's a code redesign issue and not a dogfood
functionality issue; but that doesn't mean we can't do it sooner if we have
time.

Comment 7

[Ben Bucksch (:BenB)]

I think, I really need that for tables (bug #18012), reassigning to me.

Comment 8

[Ben Bucksch (:BenB)]

Design decision: To get some flexible structure, we have to design a browser
minus interactivity plus different linebreak strategies (filled for tables,
plain, flowed etc.). We not just have an existing design, but also a lot of
code, we can reuse: NGLayout.

The plan is to at least reuse everything until nsCSSFrameConstructor (see
<http://www.mozilla.org/docs/url_load.html>), propably some of the nsIFrames.

The problem is my limited knowledge about NGLayout and XPCOM. More detailed: I
don't know, how to decide somewhere at the webshell, which "frameset" to use.

Comment 9

[Ben Bucksch (:BenB)]

I don't think, I'll work on that anytime soon. HELP WANTED.

Comment 10

[rubydoo123]

this function was not part of the initial design specs and would require
architectual changes, marking wontfix

Comment 11

[sujay]

verified in 1/19 build.

Comment 12

[Ben Bucksch (:BenB)]

beppe:
> marking wontfix
sujay:
> verified in 1/19 build.
LOL

Comment 13

[leger]

Bulk move of all "Output" component bugs to new "DOM to Test Conversion" 
component.  Output will be deleted as a component.

Comment 14

[Akkana Peck]

Sorry for the spam!  But apparently all these closed bugs need to have their
target milestones changed since M19 and M20 are going away.  Since they're
allready closed, I'm choosing M18.