Closed Bug 95959 Opened 23 years ago Closed 22 years ago

[RFE] Mozilla does not support XSL:FO or XML Formatting Objects

Categories

(Core :: Layout, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mal0rd, Unassigned)

References

()

Details

(Whiteboard: WONTFIX? -- bad for the web)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3+) Gecko/20010811
BuildID:    2001081108

XSL Formatting Objects are the future of the Web.  Mozilla should support them,
because they are better than CSS.

Reproducible: Always
Steps to Reproduce:
Visit a page that uses FO objects, commonly the page has a FO extension of it
uses a XSL stylesheet with FO objects.
Confirming, this is a valid RFE...

Not sure which component though, layout?
Assignee: kvisco → asa
Status: UNCONFIRMED → NEW
Component: XSLT → Browser-General
Ever confirmed: true
QA Contact: kvisco → doronr
Summary: Mozilla does not support XSL:FO or XML Formatting Objects → [RFE]Mozilla does not support XSL:FO or XML Formatting Objects
is there some sort of spec page for this?
Summary: [RFE]Mozilla does not support XSL:FO or XML Formatting Objects → [RFE] Mozilla does not support XSL:FO or XML Formatting Objects
David Baron: I don't think that your argument holds.  I read your links.  You 
are missing that fact that the user has the source XML without any formatting, 
and that is the conveyor of meaning.  HTML/CSS does not have any meaning 
whatsoever.  It is mearly style.  The Formatting Objects are for presentation 
just like CSS, but done in the standard XML, instead of a seperate format.

A quote from the 2nd link:
Unfortunately, when transforming documents into XFO, all semantics is removed 
and only the human presentation is left. 

This is completely untrue.  The semantics are 100% intact, unlike HTML w/CSS.  
Remember, XSL:FOs are like CSS, they transform the XML tags into something the 
user can see, but they do it BROWSER-SIDE, so the source XML is still there.  
XSL is just better than CSS.  If you want to know why read the W3C 
recomendation.
> David Baron: I don't think that your argument holds.  I read your links.  You 
> are missing that fact that the user has the source XML without any formatting, 
> and that is the conveyor of meaning.  HTML/CSS does not have any meaning 
> whatsoever.

HTML has well known semantics, as do other XML applications.  (CSS can be used
with XML just as with HTML.)  It's arbitrary made-up XML that has no semantics.

> It is mearly style.  The Formatting Objects are for presentation 
> just like CSS, but done in the standard XML, instead of a seperate format.

XML is not ideal for everything.  It was designed as a metalanguage for
markup languages.  I wouldn't want to write programs in XML.  Similarly,
I wouldn't want to write stylesheets in XML.  XML was designed for
documents, and I suspect that this fad of making every data format use
XML will go away once people realize how bloated it is and how difficult
it is to use.  (XSLT is *very* difficult to use, for example.)

> A quote from the 2nd link:
> Unfortunately, when transforming documents into XFO, all semantics is removed 
> and only the human presentation is left. 
>
> This is completely untrue.  The semantics are 100% intact, unlike HTML w/CSS.  
> Remember, XSL:FOs are like CSS, they transform the XML tags into something the 
> user can see, but they do it BROWSER-SIDE, so the source XML is still there.  
> XSL is just better than CSS.  If you want to know why read the W3C 
> recomendation.

You completely misunderstood the point that was being made.  The point was that
unless the XSL-FO specification forbids receiving XSL-FO directly from the web
but requires that they be produced from a transformation (and how would one
enforce that it wasn't a null transformation?), people would just stick XSL-FO
on the web and the semantic web would be destroyed forever.
David Baron: HTML has well defined semantics?  No it doesn't, that is why XML 
is needed.  HTML only tells presentation, and doesn't give a good idea to a 
computer what the data is about.  Good XML portrays the data, and the 
stylesheet (XSL or CSS) displays it.
It seems from your last post that the reason you don't want XSL to be 
implimented is because it is a "fad" and bloated, hard to use, ect...
But it IS more powerful that any version of CSS.  And I can use a standard XML 
parser to scan it.
Your last paragraph seems to suggest that XML-FO should require the source XML 
to be transmitted with a stylesheet instead of already processed.  I agree that 
that is the way that it should be done.  But currently, with websites written 
in XML are normally transformed into HTML/CSS before the end user sees it.  
That is bad, HTML has poor semantics.
> David Baron: HTML has well defined semantics?  No it doesn't, that is why XML 
> is needed.  HTML only tells presentation, and doesn't give a good idea to a 
> computer what the data is about.

The meaning of the EM element is defined by an international standard (the ISO
standardized version of HTML 4).  The meaning of the foobar element, or any
other element some random XML application makes up, is not.

> It seems from your last post that the reason you don't want XSL to be 
> implimented is because it is a "fad" and bloated, hard to use, ect...
> But it IS more powerful that any version of CSS.  And I can use a standard XML 
> parser to scan it.

No, the reason I don't want it to be implemented is because it's a serious
threat to accessibility (unlike XHTML).  Furthermore, CSS3 will probably have
most of the other things that XSL-FO have, and probably some other things that
aren't even possible with XSL-FO (such as pseudo-elements).

> Your last paragraph seems to suggest that XML-FO should require the source XML 
> to be transmitted with a stylesheet instead of already processed.  I agree
> that that is the way that it should be done.  But currently, with websites
> written in XML are normally transformed into HTML/CSS before the end user sees
> it.  That is bad, HTML has poor semantics.

A far better way for us to improve this situation is to work on improving our
XML+CSS support, not go off and implement XSL-FO.
Can someone please explain why this doesn't belong to XSLT? Browser-General 
doesn't want it, unless you are 100% certain this is a graveyard bug, in which 
case i think we'd be just as happy to see you drag this carpace somewhere else 
(XSLT would be just as good for a dead RFE as here)
<dbaron> timeless: Then it belongs in Layout.
Assignee: asa → karnaze
Component: Browser-General → Layout
QA Contact: doronr → petersen
This bug messes with two problems.
Serving XSL:FO over the net, and using XSL:FO in a stylesheet.
Devin, you'd hardly recognize if Mozilla did support XSL:FO, you send it as
text/plain, so it ain't XML AFA Mozilla is concerned. Hihihi.

Just read the first sentence of the XSL spec, it says *stylesheet*.

So it might be worth considering using XSL:FO as result of XSLT used to display.
Simple, almost one step, pure client side stylesheet. No obfuscation of content,
or other harmful things.

(There's still pdf for those that want to just pipe visual pres over the net)

Ping to glazou, let's get more rants here.

Axel
I think that XSL-FO should be used as a style-sheet, in place of CSS.  A
client-side XSLT could be used to convert it ( if the user doesn't set there
preferences otherwise.)  Actually, if Mozilla only supported FO as a stylesheet
then I think that it would leviate many of the fears that FO's are dangerous,
becuase the source XML would always be availible.  If you go to the website with
the example I gave the page is availible in source XML/XSLT > XSL-FO.

Also, Baron's example doesn't hold.  What does EM mean? emphisis.  That is
hardly a clue as to the content.  All we know is that it is important to the
document.  It could be a proper name, a stock symbol, or a stressed word in a
paragraph.  In XML one could use the <Stock Symbol> element, and the user would
know what was contained in a tag.  What does <EM>tag</EM> referes to?  Try to
guess.  Now tell me what <Game ageGroup="children">tag</Game> referes to?

The only way that EM means anything is in context.  This is bad for computers to
parse to change to a different format (like audio).
Please, stop ranting at HTML forth and back. Thanx.
> Also, Baron's example doesn't hold.  What does EM mean? emphisis.  That is
> hardly a clue as to the content.  All we know is that it is important to the
> document.  It could be a proper name, a stock symbol, or a stressed word in a
> paragraph.

Nope.  It is defined to be the third.

>  In XML one could use the <Stock Symbol> element, and the user would
> know what was contained in a tag.

It contains the symbol?  Or the name of the company the symbol refers to?  Or
the price of the stock?  Or the amount the stock changed last Wednesday?  I
wouldn't call that well defined.  Arbtrary user-designed XML formats don't have
well defined semantics.  That's my point.

>  What does <EM>tag</EM> referes to?  Try to guess.

Emphasized text.  That's a common and well-understood concept in human-readable
documents.  It's a somewhat general concept, but it's much more specific than a
formatting concept like italic (which is also used for work titles, defining
instances of terms, headings (because it looks nice), etc.) or bold (which is
also used for defining instances, headings (because it looks nice), etc.).

> Now tell me what <Game ageGroup="children">tag</Game> referes to?

Well, what you call "tag" (which is the contents of the element) could be the
name of the game, the company that manufactures the game, the ages of the
children to which the game is appropriate, the price of the game, the date the
game will be available on the market, or many other things.
I strongly, strongly recommend that this be marked WONTFIX.

See also:
   http://lists.w3.org/Archives/Public/www-style/2000Oct/0034.html
   http://lists.w3.org/Archives/Public/www-style/2000Oct/0014.html

...in addition to the comments above.

Note that forcing the use of a stylesheet, so that XSL:FOs cannot be used on 
their own, won't work, because it is possible to write an identity XSLT 
stylesheet, and therefore it is possible to author pure XSL:FOs easily.


I ask the people who have the skill to implement XSL:FOs and wish to implement 
it in Mozilla to please e-mail me first, so that I can convince them to fix our
many, many existing bugs with our CSS renderer first. As Daniel Glazman has
said, working on XSL:FOs "is waste of neurons".
Assignee: karnaze → ian
Whiteboard: WONTFIX? -- bad for the web
Please don't misquote me, I said that XSL:FOs are a waste of neurons as a work
being done by W3C for the benefits of the World Wide Web. If I can see the
publishing industry adopting XSL:FOs for batch processing/printing, I clearly
don't see them ready to appear any time soon in dynamic environments, 'a fortiori'
on the Web. In our particuliar case, let's just say that it has an infinitesimal
priority...
giving to nobody, since Hixie's not about to implement this.
Assignee: ian → nobody
WONTFIX per comments
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
I agree 100% with this WONTFIX, thank you Ian.
You need to log in before you can comment on or make changes to this bug.