Submitted On 29-JAN-2000
omurata
World Wide Web Consortium(W3C) shows the spec of XHTML1.0
and popular web browsers are supporting HTML4.0
But Swing supports only HTML3.2
In these days, web computing is getting more vital.
JavaHelp 1.1 has poor ability to show HTML because it use Swing component(
JEditorPane )
Submitted On 30-JAN-2000
omurata
Now, World Wide Web Consortium(W3C) shows the spec of XHTML1.0 .
And popular web browsers are supporting HTML4.0
But Swing supports only HTML3.2 or less.
In these days, web computing is getting more and more vital.
JavaHelp 1.1 has poor ability to show HTML because it use Swing
component(JEditorPane )
So I think that Swing should support the newest HTML and XHTML features.
Submitted On 30-JAN-2000
omurata
Applet are to compensate for incredibly outdated browsers.
Browser's version and its supporting Java versions bring much troubles for
applets.
If Swing (the core package of Java2) will support the full features of the
current
HTML(HTML4 and XHTML),
it will solve this browser-applet problem.
If so, we can write Java applications by using HTML supporting components
and access webs
without any applets nor browsers.
Submitted On 09-FEB-2000
omurata
Should this RFE be included in J2 SEv1.4( Merlin ) ?
Submitted On 01-APR-2001
GoBabyGo
Another problem is the editing of XHTML in a JTextPane. the
text written is HTML 3.2 not XHTML.
I tried to extend HTMLWriter and HTMLEditorkit, but it is
impossible to overwrite the method emptyTag because of
private fields.
Submitted On 16-APR-2001
chujer
There's a bug in the additional source shown.
Document Type must be transitional or strict, not frameset,
if using the body element as child of the html element.
Nevertheless, this bug has my vote.
Submitted On 08-JAN-2002
barshatzkyk
I need support for well-formed HTML.
Submitted On 21-JUN-2002
s335058
HTML 4 support would be a great start...
Submitted On 18-JUL-2002
chriskuske
I concur, Java needs to have a HTML 4.0 compatible
JEditorPane.
My documents do not get rendered correctly, if at all
(besides the <META> bug that I have to workaround).
Submitted On 27-SEP-2002
iforgot
I agree we need support for XHTML and HTML 4. I am tired of seeing crazing things showing in my HTML preview window (there are probably bugs in the implementation, but why bother fixing that since it's only HTML 3.2 anyway).
Does someone know of a way to display a web page with the default web browser from a Java application ? It could be an acceptable workaround in the meantime.
Submitted On 24-JAN-2003
drm9f
Over 3 years since this was submitted and no action yet?
How about it Sun??? Give us modern HTML support!!
Submitted On 04-FEB-2003
logrosoft
Have you tried to do a good report with HTML3.2?
I think it's impossible.
Please give us a chance to work, I have a lot of people
waiting for this bug to be resolved.
Submitted On 24-MAR-2003
porika
could u please, provide support for HTML 4.0 ASAP , IT's
really late already.
Submitted On 31-OCT-2003
Duane_Gran
I would like to weigh to suggest that xhtml support would be very
helpful. In addition, if Sun could provide an XMLEditorKit
implementation that would be excellent.
Submitted On 11-NOV-2003
FarukMKhan
Yes Sun guys should have done it by now. Because it is not
really difficult. Our team could do it successfully. We do
have a few problems still. But it took 3 months for 3 of us
to do it. And with the expert swing programmers at SUN and
all the secret tools they have they can achive it very very
easily. It seems sun just doesn't have the will or the money.
Submitted On 23-FEB-2004
khsoh
At least update the documentation to tell developers what
version and what tags are supported by JEditorPane. It is
crazy to write HTML pages by trial-and-error with JEditorPane.
Submitted On 27-APR-2004
ovrubl
Also it would be grate to make a little refactoroing of
Parser HTMLWriter and HTMLEditorKit implementation to open
some private function to better handle the parsing/writting
process and to allow extending of these classes, there are
some inner-private classes in CSS and others that also would
be grate to have access. I know that this is too complex
task, but it's a root of many outstanding issues. Please let
the comunity know how it's going with this functionality,
maybe some handwork could be acceptable from our side... Thanks
Submitted On 01-JUL-2004
gautham82
Let alone HTML 4.0, CSSx and all. How about just class names with capitals in CSS ?
<HTML>
<HEAD>
<STYLE TYPE="text/css">
.red {
color: red;
}
.Green {
color: green;
}
.Blue {
color: blue;
}
.yellow {
color: yellow;
}
.gray {
color: gray;
}
.vioLet {
color: rgb(255,0,255);
}
</STYLE>
</HEAD>
<BODY>
<DIV CLASS="red">Red</DIV>
<DIV CLASS="green">green</DIV>
<DIV CLASS="Blue">blue !!!</DIV>
<DIV CLASS="Yellow">yellow !!!</DIV>
<DIV CLASS="graY">gray !!!</DIV>
<DIV CLASS="violet">violet</DIV>
</BODY>
</HTML>
You can see that the words with the '!!!' come out black (jdk1.4.2_04). Please fix atleast this as a max priority. It is a shame.
Submitted On 04-JUL-2004
GarretWilson
JEditorPane starts off with a nice conception separation between data and views, but its current implementation quickly devolves into HTML-dependency at its simplest.
For example---the hierarchy of <p>the <strong><em>very</em> bad</strong> sentence</p> has to be collapsed into something like <p>the <strong><em>very</em></strong><strong> bad</strong> sentence</p>, which is disasterous for generic XML semantics. Similarly, JEditorPane can't do generic CSS-based flowing with <foo>this is text that gets an anonymous block <bar>and this gets block flowing explicitly</bar></foo> when both foo and bar have CSS display:block defined.
My company has completely retrofitted JEditorPane so that it handles a generic XML input, applies arbitrary CSS, and dynamically flows views based upon the run-time style of the XML, complete with namespace support. Under this scenario, XHTML is simply a default association of an XHTML CSS stylesheet with the XHTML namespace, and the layout is performed agnostic to the semantics of the actual XHTML tags (in contrast to the hard-coded HTML tag semantics currently used by JEditorPane). This means that our implementation handles something like <blockquote>the list <ul><li>first item</li> <li><p>more stuff</p><p>and more</p>with others</li></ul>and more</blockquote> with ease, without XHTML-specific coding.
Our implementation is running into a bit of a problem in providing editing, simply because we have to put up with so many hard-coded assumptions in the JEditorPane architecture. For example, most of the existing editing functions assume that there is a literal '\n' at the end of each paragraph! This not only destroys the fidelity of the input, it limits an interpretation of "paragraph" to a specific HTML <p> tag (not a generalized block flow, as illustrated above), and binds a particular layout to the content, so that user editing the document can't easily insert nested block-flowed elements or change an associated stylesheet and see automatic reflow.
We would love to work with Sun to refactor and improve JEditorPane so that it's a generic XML editing and rendering engine. This is feasible; see our two products:
http://www.globalmentor.com/software/reader/
http://www.globalmentor.com/software/marmot
We already can apply CSS and flow generic XML, including XHTML, while retaining the overarching JEditorPane design. Completing the project would require Sun to banish the HTML-specific assumptions from the JEditorPane architecture. We've put seven years of work into this, and it would be nice if we could get some W3C-compliant XHTML support into the Java source code so that everyone could use it. If anyone at Sun is interested, please contact me.
Submitted On 03-AUG-2004
ed_mooney
PLEASE INCLUDE CSS support with HTML4, so the design of the pages can be independent of the HTML support - Provides much more flexibilty.
Submitted On 07-AUG-2004
carldea
I think it should support HTML, CSS, Javascript, Xul, Applets, XML etc.
Similar to what JTidy can do.
Why not open source Hot Java Browser???
-Carl
Submitted On 10-AUG-2004
Przemyslaw_d
It would by nice to get some comments from sun! Even something like "sun dont want support HTML4.0 before 2100 A.D."
Submitted On 22-AUG-2004
Lutha
I notice html looks better using java 1.5 beta2.
(better font recognition and cleaner formatting...)
However, the text looks jagged...
Submitted On 26-AUG-2004
gertas
integrate gecko engine with java (jeditorpane+bundle),
then java desktop apps kill .NETs shining designs (by IE)
Submitted On 09-SEP-2004
BenColeman_UK
This get's my vote, I've really needed this a number of times when displaying HTML content within Swing apps. Ironic really considering the number of HTML 4 / CSS sites that must be served via Java technology.
Submitted On 20-OCT-2004
shmiggle
Standards compliance for the JEditorPane is probably
a pipe dream in the near future but it would be great if support for widely used HTML and CSS was available. I'm talking about floating images right or left (align tag) and table cell borders. Oh yes and justified text (rather than centred).... and that is just the start of the list....
Submitted On 23-NOV-2004
melly_01
Now nearly 5 years past since this request for enhancement was post.
Will there be full support of HTML 4.0 in the near future?
JavaHelp and things like this then will be better significant.
Submitted On 03-JUN-2005
mcaven
A rewrite of JEditorPane to show HTML would be very nice. I am trying to show a 65 kB string with HTML code and it takes very long time to display, even on a really fast Windows computer...
Submitted On 09-AUG-2005
bparousis
It'll be a very happy day in my life when I can use JEditorPane to display just about any site on the net.
Submitted On 13-AUG-2005
mbala_k
JEditorPane must provide GOOD support for entities also. It's a MUST feature we must have it guys!!
--
Balakumar Muthu
http://i5bala.blogspot.com
http://geocities.com/i5bala/java.htm
--
Submitted On 21-OCT-2005
sils
It seems to me a very important behaviour that Sun
MUST be implement as soon as possible
Submitted On 21-NOV-2005
TheSteve0
Just wanted to let you know that bc of this bug I could not go with a JavaHelp system and instead I had to use eclipse help. Please fix this for 1.6...
Submitted On 11-JAN-2006
KentYang
Please fix it. Don't want to jump through hoops to work around this problem.
Submitted On 29-MAR-2006
no news ?
Submitted On 13-JUL-2006
SydneyCarton
Hey Guys its July 2006. This bug was reported in 1999!
Submitted On 04-AUG-2006
uvoigt
This has also an effect to the JavaHelp system. It is quite unusable with this poor CSS support of JEditorPane.
Submitted On 28-OCT-2006
s690716
[quote]
To make sure all the important features are implemented we need your help. We've created a survey to help us to understand your needs better:
http://java.sun.com/webapps/survey/display?survey_id=5370
(It might take about fifteen minutes to finish it.)
Thank you for your time.[/quote]
Wrong: "It might take about more than 7 years to finish it" (starting from submit date). Thank you for the bug database - every bug that is more than 5 years old should be a high (high high high^n) important bug...
BTW: Ask IBM/the Eclipse SWT team... for a up-to-date browser component.
Submitted On 30-AUG-2007
test
Submitted On 08-NOV-2007
It's November 2007. Few days more and this bug will celebrate its 8th years of its state of being "In progress, request for enhancement".
....
Instead of fixing bugs like this, Java stewards are busy erroding Java by formulating another language features like closures that will add unnecessary complication to the language.
Sigh!
Submitted On 25-JAN-2008
verdyp
Hmmm... Now you'll need to consider "upgrading" this bug to support:
*** HTML 5 *** (released now by W3.org)
even if you don't enforce the stricter XML validation of XHTML or don't want to enforce the XML schema. HTML 5 enhances the compatibility requirements for better interoperability, and defines stricter rules for the rendering and expected behavior (including for compatibility with reasonnable defaults), when XHTML enforces the schema by forbidding most optional extensions. What is important is the interoperability that HTML 5 provides (but not XHTML which focuses instead on reusability of documents fragments through XML parsers, for building other composite documents or data sources).
Most authors will consider that the need for XHTML is not expected (as they don't want to support reusability of their creation in other contexts than the full rendering of their HTML documents), but they do want proper rendering and behavior of their creation. HTML 4 was not enough to solve this problem, so HTML 5 is a big advance in the correct direction (it is independant of the XHTML compatibility which targets another purpose: HTML5 can still be easily made compatible with XML and XHTML).
Submitted On 25-JAN-2008
verdyp
To be more exact, HTML 5 is not completely released, but most of the changes are good practices that Java's implementation still ignores completely. There remains some undefined elements to discuss, but the HTML 5 framework is mostly complete, where the missing/discussed items are clearly emphasized with bold red insertions in the beta specification, and all the rest mostly complete (or possibly updated only to fix some obvious minor bugs that may remain, even after the finalization of the release).
Feel free to discuss the issues at W3.org if this causes problems for your implementation (notably: most remaining issues are related to DOM bindings using IDL, that have some problems when it gets mapped to actual languages like Javascript/ECMAscript or Java). It's clear that W3 is targetting ECMAscript because that's what browser developers and users will want. If you think that W3 should define direct bindings in other languages such as Java or ECMAscript (or even C#) to fix the interoperability issues please propose your schema (my opinion is that IDL should be maintained as a basic reference, but that correct bindings to ECMAscript, Java, C and C++ should also be documented, so that interoperability issues between those 3 can be documented. This should satisfy the needs for almost all other languages that have different (dynamic or static) datatyping systems.
Submitted On 18-MAY-2008
luxjava
I'm waiting!
Submitted On 13-OCT-2008
Laie_Techie
While we would all like a modern browser embedded in Java, I think that may be a bit too ambitious. Look at the resources used by the Mozilla Foundation, Microsoft, and others in trying to meet the W3C recommendations.
Instead, I suggest a SPI solution - 3rd parties can register support for different versions of different content-types.
Submitted On 17-OCT-2008
kieron.wilkinson
If its difficult, why not just make it pluggable? Then projects like Flying Saucer and Cobra can provide interfaces to provide the rendering. Of course, if you are working on all-new wizzy component (based on FC?), that is even better. :)
It's been too long not having good HTML support, and it is very useful for providing e.g. printing support without having to do Java2D stuff yourself.
Submitted On 24-FEB-2009
Eric-the-K
I also believe that HTML 3.2 is too old a standard for Java to be pegged to. Please update a newer version. In particular I would like to see support for the title attribute so we can give HTML elements tool-tips.
Submitted On 26-MAR-2009
andygrav
Ten years on and still no progress ...
It isnt good for Sun's image to leave a rfe open so long.
I even had a look at implementing it, but the api isnt that easy to program.
Can Sun at least give some indication of whether it is planned for java 7.
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
