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)
Core
Layout
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
Comment 2•23 years ago
|
||
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
XSL-FO pose a serious danger to the web. I am against implementing them in Mozilla: http://lists.w3.org/Archives/Public/www-style/1999Jun/0027.html http://people.opera.com/howcome/1999/foch.html
Reporter | ||
Comment 4•23 years ago
|
||
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.
Reporter | ||
Comment 6•23 years ago
|
||
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)
XSLT and XSL-FO are different.
Comment 10•23 years ago
|
||
<dbaron> timeless: Then it belongs in Layout.
Assignee: asa → karnaze
Component: Browser-General → Layout
QA Contact: doronr → petersen
Comment 11•23 years ago
|
||
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
Reporter | ||
Comment 12•23 years ago
|
||
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).
Comment 13•23 years ago
|
||
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.
Comment 15•23 years ago
|
||
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...
Comment 17•22 years ago
|
||
giving to nobody, since Hixie's not about to implement this.
Assignee: ian → nobody
Comment 18•22 years ago
|
||
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.
Description
•