Mozilla 1.0 Standards Bugs (feedback requested)

[Ian Hickson]

Mozilla 1.0 is coming soon, and mozilla.org have asked me to try to list
what standards compliance bugs should be highlighted in that context. As
this is an open project, I am asking for your help in doing this.

The importance criteria are apparently:

- bugs which currently cause problems on the web, or will do so in the
near future
- bugs that might come back to bite us later if we don't fix them

Unfortunately that covers a good 4000+ bugs, so we will have to narrow
them down a little if mozilla.org is to hit the target release date for
1.0 (sometime in March 2002) with the ability to say that lots of
standards compliance bugs were fixed.

Here are the bugs I have shortlisted, in no particular order, and the
reasons why:

41924 Change how layout handles broken images (alt text)
People keep complaining about this.

104035 Should use system cursor for 'pointer' (hand) on Windows
My flat mates say this is the one thing blocking their use of
Mozilla.

1777 'text-decoration' should not be drawn by children (underline)
This is one of the few major remaining CSS1 bugs.

5693 :hover should be hierarchical
This has been coming back to bite us for years.

98252 New W3C CSS page hurts Mozilla
We really should be usable on the W3C CSS page.

13213 events don't reach elements to top or left of view
This currently causes lots of problems on the web.

35984 Undeclared entities are ignored when external DTD not found
XML error handling is critical to the use of XML.

3935 mozilla-native psuedo classes and properties should be marked as such
This is hugely important to the future of the web.

86276 split to containing block is not working for XML
A major bug in XML-in-CSS styling.

34297 form controls with style="display: none;" unsuccessful in Mozilla
This is another bug that keeps biting people.

72360 Crash caused by attempting to create a circular frame list in tables
This would block the use of CSS tables due to it crashing Mozilla.

78094 Floats Are Broken
This is a very important CSS1 area.

97726 line-height&font-size
Serious W3C CSS1 test suite failure.

15405 Root element is stretching vertically to fit the viewport
Another serious CSS1 bug.

46918 line-breaking bug caused by +ve margin-right on inline elements
3490 line-breaking bug caused by -ve margin-right on inline elements
A couple of serious CSS1 bugs very visible on the W3C test suite.

There are plenty more important bugs -- but I'd like your help to decide
which are the most important. Please reply to this thread (and cc me)
giving a bug number and summary and explaining why your bug needs to be
fixed to match the two importance criteria. (Please keep your replies to
the n.p.mozilla.layout newsgroup.)

Note that Gerv has told me that this is not a list of "blockers" -- 1.0
might well ship with none of these bugs fixed. It's just supposed to be
an indicator of what bugs mozilla.org would _like_ us to work on.

--
Ian Hickson

[jesus X]

Ian Hickson wrote:
> 104035 Should use system cursor for 'pointer' (hand) on Windows
> My flat mates say this is the one thing blocking their use of
> Mozilla.

Out of everything that needs done, THIS is what they're waiting on? This is
probably one of the most trivial "blockers" I've ever heard of. I mean, I'm not
saying don't do it (although I'll be changing my hand cursor to the NS style
hand momentarily), but for someone to wait for THIS to use a product, that's
just lame. :)

> 98252 New W3C CSS page hurts Mozilla
> We really should be usable on the W3C CSS page.

I noticed this a while ago. Yikes. Maybe until this is fixed we can just code
Moz to crash when this URL is visited? :)

--
jesus X [ Booze-fueled paragon of pointless cruelty and wanton sadism. ]
email [ jesusx @ who.net ]
tag [ The Universe: It's everywhere you want to be. ]
warning [ I am an American. Of this, I am proud. ]

[Jon Smirl]

I'd like to see this get implemented:
http://bugzilla.mozilla.org/show_bug.cgi?id=51684

This would allow work on other standards like SVG and MathML to carry on
after Mozilla 1.0 is released. Right now these other languages are built
into Mozilla instead of being loaded as a module.

--
Jon Smirl
jons...@mediaone.net

[L. David Baron]

On Sun, 21 Oct 2001, Jon Smirl wrote:
> I'd like to see this get implemented:
> http://bugzilla.mozilla.org/show_bug.cgi?id=51684
>
> This would allow work on other standards like SVG and MathML to carry on
> after Mozilla 1.0 is released. Right now these other languages are built
> into Mozilla instead of being loaded as a module.

While this sounds nice, I don't think we should hold up Mozilla 1.0 while
we spend a few years rewriting the layout engine from scratch, again.

-David

--
L. David Baron <URL: http://www.people.fas.harvard.edu/~dbaron/ >

[Jon Smirl]

There is no need to do a whole rewrite, the layout engine is just hard
linking to classes where there should be a component interface instead. By
looking at the SVG branch you can see exactly where the interfaces need to
be created. Nothing would be changed in the way layout works.

--
Jon Smirl
jons...@mediaone.net

[Bernd Mielke]

http://bugzilla.mozilla.org/show_bug.cgi?id=41262

I think this bug is not only about CSS2 compliance (the collapsed border
model) but also bites with rule's problems (aka HTML4 compliance). It
is in my opinion the worst html-table problem (but not in my reach :-().

Bernd

[L. David Baron]

On Sun, 21 Oct 2001, Jon Smirl wrote:

> There is no need to do a whole rewrite, the layout engine is just hard
> linking to classes where there should be a component interface instead. By
> looking at the SVG branch you can see exactly where the interfaces need to
> be created. Nothing would be changed in the way layout works.

We use too much COM in layout already. The overhead of virtual function
calls (missed branch predictions, cache misses, etc.) costs at least 5% of
our page load time, probably more like 10% or 15% or perhaps even more.
Are you suggesting we use more COM? Where?

Furthermore, just turning things into interfaces isn't satisfactory --
those interfaces actually have to work when code that does something
different from what the existing code does is plugged in. That requires
interfaces that are actually designed for multiple implementations rather
than interfaces that are designed as a not-quite-COM interface to connect
one known class to another known class. That requires major work in
layout.

[Magnus W]

http://bugzilla.mozilla.org/show_bug.cgi?id=35274

clip is broken, and it's quite visible (if you know what's happening;
otherwise, it's just really, really frustrating) on some sites. With clip
not functioning as it should, many "DHTML" applications get very hard to
code. "DHTML" stuff is increasing in popularity. Thus, web developers will
swear over this one. I already do.

[Mike Jaques]

I would also ask that all 4xp bugs get a look prior to 1.0 declaration.
Mozilla 1.0 and whatever Netscape release that springs forth from it should
be able to do EVERYTHING 4.x does so we can label it as such and use it as a
reason for everyone (enterprise users mostly) to finally give up their
entiquated 4.x browser and adopt Mozilla 1.0/Netscape 6.x

I'm sure a few of the below bugs probably include 4xp keywords, but last i
knew there was a bunch of them left, and IMHO they should all be vanquished
prior to 1.0 classification.

Mike J

"Ian Hickson" <i...@hixie.ch> wrote in message
news:3BD2EBA3...@hixie.ch...

[DeMoN LaG]

"Mike Jaques" <moo...@home.com> wrote in
news:9qvfo3$pl...@ripley.netscape.com, on 21 Oct 2001:

> I would also ask that all 4xp bugs get a look prior to 1.0
> declaration. Mozilla 1.0 and whatever Netscape release that springs
> forth from it should be able to do EVERYTHING 4.x does so we can
> label it as such and use it as a reason for everyone (enterprise
> users mostly) to finally give up their entiquated 4.x browser and
> adopt Mozilla 1.0/Netscape 6.x
>

Mozilla could instead call 1.0 "Version 12." People would see the 12 vs
IE6 and Netscape 4 and say "wow, it's 3 times as good as Netscape 4 and
twice as good as IE 6 is!"

--
ICQ: N/A (temporarily)
AIM: FlyersR1 9
email: de_on-lag@ho_e.co_
_ = m

[Justin H.]

55987 using CSS display: xxx on IFRAMES causes data loss
data loss! nuff said.

42287 Need to strip whitespace from ends of non-CDATA attributes in HTML
87894 Whitespace (at least leading and trailing) should be trimmed
94174 negocios.pt - URL malformed when HTML code like <A href="
/categoria/doc.asp?cd=6365 " >
47078 Newlines are not converted to whitespace in attributes
95754 Should strip spaces from ends of CDATA attributes
Attribute whitespace handling bugs (CDATA and non-CDATA) tends to break
images, links, etc... This is only a spall sampling of the large amount
of these bugs that have been filed (duped and non-duped). This doesn't
include any for XML whitespace handling, btw. Not to mention that
WYSIWYG editors tend to make this sort of mistake more often than is
comfortable for my taste.

Justin H.
--
"If it's in stock, we've got it!"
-slogan for a tire store

[Jon Smirl]

So the SVG people are just wasting their time? A full SVG implementation
(based on the size of the Adobe one) could add another megabyte each to
gkcontent and gklayout. XUL should be it's own component too. The new XPCOM
interface would allow SVG, MathML and XUL to be dynamically loaded based on
the namespace of the incoming page.

The longer this gets deferred the worse it is going to get.

--
Jon Smirl
jons...@mediaone.net

[L. David Baron]

On Sun, 21 Oct 2001, Jon Smirl wrote:

Allowing SVG and MathML to be drop-in components requires much more that
just changing some interfaces. It requires redesigning the content sink
and frame construction code, and probably also significant changes to the
way reflow works (and probably making so many functions virtual that our
speed would cut perceptibly).

What's the big advantage of drop-in components anyway? What's wrong with
allowing people to redistribute a new layout dll that has mathml built in?
(Yes, drop-in components would be nicer, but are the worth a significant
performance cost for the cost of an installation that only happens once?)

That said, people are thinking about how to make layout extensible.
However, the solution is not sprinkling |virtual| all over the code in the
hopes that the layout engine will eventually be slow enough that it's
extensible. :-) It should be neither necessary nor sufficient.

[Jon Smirl]

"L. David Baron" <dba...@fas.harvard.edu> wrote in message
news:Pine.OSF.4.33.011021...@is03.fas.harvard.edu...

> What's the big advantage of drop-in components anyway? What's wrong with
> allowing people to redistribute a new layout dll that has mathml built in?
> (Yes, drop-in components would be nicer, but are the worth a significant
> performance cost for the cost of an installation that only happens once?)

Because we today have MathML, SVG and XUL. People are already working on
ChemicalML, MoleculeML, MusicML, etc. Each of the will have to built into
the source code of layout/content. Ultimately we have to make plugable
markup languages based on XML namespaces. Componentizing also allows the
development of these languages to proceed independently of Mozilla.

If Mozilla 1.0 ships without SVG, when SVG ships it will cause an immediate
fork in the Mozilla browser base, those with SVG and those without. The
later SVG capable Mozilla may also have a bunch of bugs fixed it other areas
causing bigger incompatibilities.

I need to see some numbers to substantiate that virtual functions are 15% of
layout time. In my experience with layout engines the dominate time consumer
is measuring text.

> That said, people are thinking about how to make layout extensible.
> However, the solution is not sprinkling |virtual| all over the code in the
> hopes that the layout engine will eventually be slow enough that it's
> extensible. :-) It should be neither necessary nor sufficient.

Sprinkling virtual is not the solution. Designing an IDL file is the correct
solution.

--
Jon Smirl
jons...@mediaone.net

[Jesse Ruderman]

> 41924 Change how layout handles broken images (alt text)
> People keep complaining about this.

Is that bug for implementing a specific spec, or is it as vague as the
summary makes it sound? Are its dups really dups, or should some of them be
wontfix or dependent?

[L. David Baron]

On Sun, 21 Oct 2001, Jon Smirl wrote:

> "L. David Baron" <dba...@fas.harvard.edu> wrote in message
> news:Pine.OSF.4.33.011021...@is03.fas.harvard.edu...
> > What's the big advantage of drop-in components anyway? What's wrong with
> > allowing people to redistribute a new layout dll that has mathml built in?
> > (Yes, drop-in components would be nicer, but are the worth a significant
> > performance cost for the cost of an installation that only happens once?)
>
> Because we today have MathML, SVG and XUL. People are already working on
> ChemicalML, MoleculeML, MusicML, etc. Each of the will have to built into
> the source code of layout/content. Ultimately we have to make plugable
> markup languages based on XML namespaces. Componentizing also allows the
> development of these languages to proceed independently of Mozilla.

That's great, and it should be a goal of Mozilla eventually, but the
layout engine was not designed to be extensible, and we'd like to have a
Mozilla 1.0 well before anyone has time to redesign the layout engine.

> If Mozilla 1.0 ships without SVG, when SVG ships it will cause an immediate
> fork in the Mozilla browser base, those with SVG and those without. The
> later SVG capable Mozilla may also have a bunch of bugs fixed it other areas
> causing bigger incompatibilities.

Then people who want SVG can upgrade to 1.1.

> I need to see some numbers to substantiate that virtual functions are 15% of
> layout time. In my experience with layout engines the dominate time consumer
> is measuring text.

I said known to be 5%, perhaps 10%-15% or more. My evidence for the 5%
was http://bugzilla.mozilla.org/show_bug.cgi?id=104336 (in particular, the
2001-10-16 22:21 comment). If deCOMtaminating one class gets us 5%,
10%-15% or more is a reasonable extrapolation.

We do spend a bit of time measuring text, but not all that much compared
to style resolution, all the function call overhead, copying of strings,
state buildup and teardown, etc. On typical pages (as measured by the
i-bench HTML load speed test, which I happen to have a profile of lying
around -- I don't think jrgm's tests, which cover a greater variety, would
yield results all that different) around 13% of the page load time is
spent in Reflow, and only 12% of that time (or 1.5% of the total) is spent
measuring text. And that's on Linux, with the costs of X11.

> > That said, people are thinking about how to make layout extensible.
> > However, the solution is not sprinkling |virtual| all over the code in the
> > hopes that the layout engine will eventually be slow enough that it's
> > extensible. :-) It should be neither necessary nor sufficient.
>
> Sprinkling virtual is not the solution. Designing an IDL file is the correct
> solution.

That requires designing an interface that will work, implementing the
interface and implementing the code that uses the interface. If you can
do that in the next few months without causing significant regressions,
your contribution would be welcome. If not, I think it's a reasonable
goal for Mozilla 2.0, but not for 1.0.

[Mike Jaques]

Sorry, I shoulda been more clear, Sundays have my brain in a haze. Within
reason Everything 4.x can do, given that there is some functionality in 4.x
we don't want or need anymore, and some that would need introduction of new
features :) Simple 4.x bugs that fit the goal of CSS-1/2 XUl1.0, or other
standards compliance, as well as major page layout issues on top100 sites
(as long as its mozilla at error, not the code on the page), definately
should be looked at atleast, if not fixed.

There are 485 outstanding 4xp bugs at this very moment, 80-90% (guessing,
maybe I am wrong) of them I bet are not feature related persay, but moreso
compatibilty or broken features already in place and need to be fixed.

I'm not nitpicking, just wondering what type of push there is out there to
get to as close to 4xp parity as possible there is before 1.0 :)

> 4.x parity is not a goal for 1.0, because it is not achievable in the
> timeframe. Getting to 4xp would require writing and landing several new
> features, and that is incompatible with our goal of stabilising and
> branching.
>
> Any bug which is important which is 4xp should be picked up under the
> other criteria. For example, a standards problem we have in something
> that works fine in IE and 4.x is 4xp - it will be picked up not because
> of that, but because it's something in common use on the web, so fits
> under our criteria for Standards bugs.
>
> Mozilla will eventually reach feature-parity with 4.x. It will not do so
> in four milestones' time.
>
> Gerv
>

[Chris Hoess]

In article <3BD34C80...@whidbey.net>, Justin H. wrote:
> 42287 Need to strip whitespace from ends of non-CDATA attributes in HTML
> 87894 Whitespace (at least leading and trailing) should be trimmed
> 94174 negocios.pt - URL malformed when HTML code like <A href="
> /categoria/doc.asp?cd=6365 " >
> 47078 Newlines are not converted to whitespace in attributes
> 95754 Should strip spaces from ends of CDATA attributes

95754 is a dupe of 87894 and I have marked it as such.

47078 is primarily held up by the fact that line breaks don't work now in
tooltips; once they do, authors can insert them using "&#10;&#13;" and we
can implement the small change necessary (strict mode only-Hixie tells me
that some braindead scripts pass large wads of text around in attributes
somehow, and stripping linefeeds will break them).

> Attribute whitespace handling bugs (CDATA and non-CDATA) tends to break
> images, links, etc... This is only a spall sampling of the large amount
> of these bugs that have been filed (duped and non-duped). This doesn't
> include any for XML whitespace handling, btw. Not to mention that
> WYSIWYG editors tend to make this sort of mistake more often than is
> comfortable for my taste.
>

Hmm. *Do* we have any bugs in XML whitespace handling? I'd assumed that
expat handled it properly (after all, jclark wrote it), and left it at
that...

--
Chris Hoess

[markus hübner]

One thing not to forget about is DHTML.
The current performance is causing inconveniences and DHTML is seen
as a crucial feature among state-of-the-art browsers.

Although this is not necessarily related to stnadards I think it has
a major impact on the success of mozilla1.0

[Vadim Plessky]

On Sunday 21 October 2001 21:49, Mike Jaques wrote:
| I would also ask that all 4xp bugs get a look prior to 1.0 declaration.
| Mozilla 1.0 and whatever Netscape release that springs forth from it
| should be able to do EVERYTHING 4.x does so we can label it as such and use
| it as a reason for everyone (enterprise users mostly) to finally give up
| their entiquated 4.x browser and adopt Mozilla 1.0/Netscape 6.x
|
| I'm sure a few of the below bugs probably include 4xp keywords, but last
| i knew there was a bunch of them left, and IMHO they should all be
| vanquished prior to 1.0 classification.

There are, basically, 2 possibilities:
1) to be compatible with Netscape 4.7, and bring forward a lot of efforts
fixing compatibility issues (with *legacy* product)
2) to be compatible with W3C standards (CSS/DOM)
I prefer second option :-)
As far as I have seen on Bugzilla, there are only around 500 CSS bugs
targeted for Mozilla 1.0 release.
Taking into consideration remaining timeframe, I think it's very much
possible to fix these 500 bugs. (it's just about 80 bugs per month)

| Mike J
|
| "Ian Hickson" <i...@hixie.ch> wrote in message
| news:3BD2EBA3...@hixie.ch...
|
| > Mozilla 1.0 is coming soon, and mozilla.org have asked me to try to
| > list what standards compliance bugs should be highlighted in that
| > context. As this is an open project, I am asking for your help in doing
| > this.
| >
| > The importance criteria are apparently:
| >
| > - bugs which currently cause problems on the web, or will do so in the
| > near future
| > - bugs that might come back to bite us later if we don't fix them
| >
| > Unfortunately that covers a good 4000+ bugs, so we will have to narrow
| > them down a little if mozilla.org is to hit the target release date for
| > 1.0 (sometime in March 2002) with the ability to say that lots of
| > standards compliance bugs were fixed.
| >

* {display: marker}, {display: compact}, {display: run-in}
* context generation
* display: inline-block from CSS3 (as it's already implemented in MS IE6 and
MacIE5)
* CSS in TABLEs (so, it's CSS2 but needs to be implemented)

| > Here are the bugs I have shortlisted, in no particular order, and the
| > reasons why:
| >

| > 98252 New W3C CSS page hurts Mozilla
| > We really should be usable on the W3C CSS page.

this should be top priority, no questions

| >
| > 78094 Floats Are Broken
| > This is a very important CSS1 area.

Indeed.

| >
| > 97726 line-height&font-size
| > Serious W3C CSS1 test suite failure.

I vote for this, too.

| >
| > 15405 Root element is stretching vertically to fit the viewport
| > Another serious CSS1 bug.
| >
| > 46918 line-breaking bug caused by +ve margin-right on inline elements
| > 3490 line-breaking bug caused by -ve margin-right on inline elements
| > A couple of serious CSS1 bugs very visible on the W3C test
| > suite.
| >
| > There are plenty more important bugs -- but I'd like your help to
| > decide which are the most important. Please reply to this thread (and
| > cc me) giving a bug number and summary and explaining why your bug
| > needs to be fixed to match the two importance criteria. (Please keep
| > your replies to the n.p.mozilla.layout newsgroup.)
| >
| > Note that Gerv has told me that this is not a list of "blockers" -- 1.0
| > might well ship with none of these bugs fixed. It's just supposed to be
| > an indicator of what bugs mozilla.org would _like_ us to work on.

There is nothing more important than compatibility with W3C standards.
If Mozilla 1.0 released without completed CSS1 (and taking into consideration
launch time, Mar.2002 - CSS2), it will be a big failure.
As I have mentioned, there are only 500 CSS bugs targeted at Mozilla 1.0
release. Most of them are quite valid and sound.
| >
| > --
| > Ian Hickson

--

Vadim Plessky
http://kde2.newmail.ru (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/

[Gervase Markham]

Mike Jaques wrote:

> Sorry, I shoulda been more clear, Sundays have my brain in a haze. Within
> reason Everything 4.x can do, given that there is some functionality in 4.x
> we don't want or need anymore, and some that would need introduction of new
> features :) Simple 4.x bugs that fit the goal of CSS-1/2 XUl1.0, or other
> standards compliance, as well as major page layout issues on top100 sites
> (as long as its mozilla at error, not the code on the page), definately
> should be looked at atleast, if not fixed.

If they are important, these bugs should be picked up under other
criteria. Your point that only 10% of the bugs marked 4xp are ones you
think we need to fix for 1.0 shows that 4xp is not really a useful
indicator.

Please use a newsreader that respects Followup-To: :-)

Gerv

[Gervase Markham]

markus hübner wrote:

> One thing not to forget about is DHTML.
> The current performance is causing inconveniences and DHTML is seen
> as a crucial feature among state-of-the-art browsers.
>
> Although this is not necessarily related to stnadards I think it has
> a major impact on the success of mozilla1.0

Name some bugs, dude :-) Are they already linked to the performance
meta-bug? If not, contact cath...@netscape.com and tell her about them.

Gerv

[Justin H.]

Chris Hoess wrote:
>
> In article <3BD34C80...@whidbey.net>, Justin H. wrote:
> > 42287 Need to strip whitespace from ends of non-CDATA attributes in HTML
> > 87894 Whitespace (at least leading and trailing) should be trimmed
> > 94174 negocios.pt - URL malformed when HTML code like <A href="
> > /categoria/doc.asp?cd=6365 " >
> > 47078 Newlines are not converted to whitespace in attributes
> > 95754 Should strip spaces from ends of CDATA attributes
>
> 95754 is a dupe of 87894 and I have marked it as such.
>
> 47078 is primarily held up by the fact that line breaks don't work now in
> tooltips; once they do, authors can insert them using "&#10;&#13;" and we
> can implement the small change necessary (strict mode only-Hixie tells me
> that some braindead scripts pass large wads of text around in attributes
> somehow, and stripping linefeeds will break them).

I'm sure there are going to be several whitespace bugs that are marked
"Tech Evangalism" that should be dupes, and others marked New that just
haven't been duped yet. However, I was just pointing out that the total
number of bugs showing this problem should be an indication of how much
of a problem it is. :-)

> > Attribute whitespace handling bugs (CDATA and non-CDATA) tends to break
> > images, links, etc... This is only a spall sampling of the large amount
> > of these bugs that have been filed (duped and non-duped). This doesn't
> > include any for XML whitespace handling, btw. Not to mention that
> > WYSIWYG editors tend to make this sort of mistake more often than is
> > comfortable for my taste.
> >
>
> Hmm. *Do* we have any bugs in XML whitespace handling? I'd assumed that
> expat handled it properly (after all, jclark wrote it), and left it at
> that...

Hrm. You may be right on this one. I think I misread a couple of bugs
that specifically mentioned XML whitespace handling as doing it
*right*. Sorry!

[xxx]

Ian Hickson wrote:
>

> 34297 form controls with style="display: none;" unsuccessful in

This is critical problem in all my major web projects, with this and
couple of other DOM-based form handling bugs (like need to use
.defaultValue instead of .value, don't remember the number) fixed I can
use Mozilla as a official IE55 equivalent for my clients.

(which is something I'm trying to do since maybe February 01 - as far as
I'm concerned we're so frustratingly close...)

> 1777 'text-decoration' should not be drawn by children (underline)

> 5693 :hover should be hierarchical

> 78094 Floats Are Broken

> 15405 Root element is stretching vertically to fit the viewport

Those are really annoying because I hit them quite often, the
workarounds are just and harder to maintain.

- Robert

[Bernd Mielke]

Hixie,

haven't you done this work already, a query for bugs with a status with
'Hixie' gives a nearly perfect coverage of the most critical layout bugs.

http://bugzilla.mozilla.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_file_loc_type=allwordssubstr&status_whiteboard=hixie&status_whiteboard_type=allwordssubstr

Bernd

[James Lariviere]

"Real" Persistant Support for alternate style sheets:
--(6782)--[RFE] UI for alternate and user stylesheets [IMPORT] [AltSS]
--(51692)--[RFE] Used stylesheet should be stored in history

This is probably one of the coolest features that IE lacks and I wish
really implemented in mozilla.

Right now mozilla only supports basic, one view, support for altSS. Style
choices should be remembered for the whole site not just for one page.
Everyone loves skinnable programs (mozilla, winamp, xmms, etc...). AltSS
offers webdevelopers the chance to "skin" their own site.

my $.02 :-)

James Lariviere

[Tim Rowley]

Ian Hickson wrote:

> There are plenty more important bugs -- but I'd like your help to decide
> which are the most important. Please reply to this thread (and cc me)
> giving a bug number and summary and explaining why your bug needs to be
> fixed to match the two importance criteria. (Please keep your replies to
> the n.p.mozilla.layout newsgroup.)

http://bugzilla.mozilla.org/show_bug.cgi?id=53597

Mozilla really needs to get a consistent view of gamma, since the
current PNG/MNG-only gamma correction makes those formats pretty
much useless for web/chrome developers since they can't match the
colors with HTML or CSS.

-tor

[markus hübner]

oh, I forgot!
It's best to mention tracking
"tracking: poor performance using DHTML"
http://bugzilla.mozilla.org/show_bug.cgi?id=21762

:: markus

[Jeffrey Yasskin]

I'm trying to get tracking bugs, but I may have missed them.

MathML: 15391 - MathML not enabled in nightly builds
MathML is essential to displaying math on the web. Wouldn't it be great if
Mozilla was the first browser to implement it?

SVG: 80142 - get new svg code into cvs
Only the coolest image format ever.

XSLT in general; I can't find a tracking bug.
XSLT is essential for displaying XML on the web. In particular:
XSLT: 95249 - Mozilla freezes on large XML document with XSLT stylesheet
makes large pages impossible

Jeffrey Yasskin

[Bradley Baetz]

On Wed, 24 Oct 2001 15:50:00 -0500, Jeffrey Yasskin <jyas...@mail.utexas.edu> wrote:
>SVG: 80142 - get new svg code into cvs
>Only the coolest image format ever.
>

As mentioned in npm.svg, while I really really really want this code in
CVS ASAP (like before more files get shuffled arround the tree :), its not
going to be turned on by default for 1.0.

We don't need Yet Another half-done implementation which web developers
will have to work arround.

Bradley

[Peter Van der Beken]

Jeffrey Yasskin wrote:

> XSLT in general; I can't find a tracking bug.

What do you mean with "XSLT in general"? This is a little broad imo.

> XSLT is essential for displaying XML on the web.

Well, not really. CSS is more important imho. But hey, XSLT is important
too ;).

> In particular:
> XSLT: 95249 - Mozilla freezes on large XML document with XSLT stylesheet
> makes large pages impossible

Huge pages :). It is being worked on as part of another bug right now. We'll need to find out what's slowing it down after that lands, so it's hard to tell right now whether we'll have a handle on it for 1.0.

Peter

[Jeffrey Yasskin]

"Peter Van der Beken" <pet...@netscape.com> wrote in message
news:3BD74F31...@netscape.com...

> Jeffrey Yasskin wrote:
>
> > XSLT in general; I can't find a tracking bug.
>
> What do you mean with "XSLT in general"? This is a little broad imo.

Well, it would be nice if we could say XSLT was "fully supported" by 1.0.
That may be too broad, but it's just playing catch-up with Microsoft.

> > XSLT is essential for displaying XML on the web.
>
> Well, not really. CSS is more important imho. But hey, XSLT is important
> too ;).

CSS can be used to style a document that's already ordered correctly. But it
can't reorder a document, and it has some trouble with generated content.
For example, the W3C's XML-based recommendations can't be displayed using
just CSS.
I agree that CSS is more important overall, since it's also very useful for
styling HTML.

Thanks. :)

Jeffrey Yasskin

[Jeffrey Yasskin]

"Bradley Baetz" <bba...@cs.mcgill.ca> wrote in message
news:slrn9teapu...@banana.home...

Just my opinion, but I'd rather a half-done implementation than none at all.
At least then the user will see something (usually correct) where an SVG
graphic should be. As an analogy, should Netscape 4.x have dropped all CSS
support just because the implementation it did have was buggy?

Jeffrey Yasskin

[Bradley Baetz]

On Wed, 24 Oct 2001 23:10:02 -0500, Jeffrey Yasskin
<jyas...@mail.utexas.edu> wrote:

>> We don't need Yet Another half-done implementation which web developers
>> will have to work arround.
>
>Just my opinion, but I'd rather a half-done implementation than none at all.
>At least then the user will see something (usually correct) where an SVG
>graphic should be.

Well, the SVG sepc does have a category for a static viewer, and a way for
a page to test availablity of teh dynamic stuff (using the DOM core
hasFeature method). So once we implement the static stuff, then we'll see.
Regardless, it will not happen for 1.0.

> As an analogy, should Netscape 4.x have dropped all CSS
>support just because the implementation it did have was buggy?
>
>Jeffrey Yasskin
>

Followups set.

Bradley

[Chris Hoess]

In article <9r8321$pd...@ripley.netscape.com>, Jeffrey Yasskin wrote:
>
> Just my opinion, but I'd rather a half-done implementation than none at all.
> At least then the user will see something (usually correct) where an SVG
> graphic should be. As an analogy, should Netscape 4.x have dropped all CSS
> support just because the implementation it did have was buggy?
>

Yes.

--
Chris Hoess

[Jonas Sicking]

Actually, this summs up pretty much what I want...

http://www.e.kth.se/~e97_jsi/moz1.mp3

: )

/ Sicking

"Ian Hickson" <i...@hixie.ch> wrote in message
news:3BD2EBA3...@hixie.ch...
> Mozilla 1.0 is coming soon, and mozilla.org have asked me to try to list
> what standards compliance bugs should be highlighted in that context. As
> this is an open project, I am asking for your help in doing this.
>
> The importance criteria are apparently:
>
> - bugs which currently cause problems on the web, or will do so in the
> near future
> - bugs that might come back to bite us later if we don't fix them
>
> Unfortunately that covers a good 4000+ bugs, so we will have to narrow
> them down a little if mozilla.org is to hit the target release date for
> 1.0 (sometime in March 2002) with the ability to say that lots of
> standards compliance bugs were fixed.
>

> Here are the bugs I have shortlisted, in no particular order, and the
> reasons why:
>

> 41924 Change how layout handles broken images (alt text)
> People keep complaining about this.
>
> 104035 Should use system cursor for 'pointer' (hand) on Windows
> My flat mates say this is the one thing blocking their use of
> Mozilla.
>

> 1777 'text-decoration' should not be drawn by children (underline)

> This is one of the few major remaining CSS1 bugs.
>

> 5693 :hover should be hierarchical

> This has been coming back to bite us for years.
>

> 98252 New W3C CSS page hurts Mozilla
> We really should be usable on the W3C CSS page.
>

> 13213 events don't reach elements to top or left of view
> This currently causes lots of problems on the web.
>
> 35984 Undeclared entities are ignored when external DTD not found
> XML error handling is critical to the use of XML.
>
> 3935 mozilla-native psuedo classes and properties should be marked as
such
> This is hugely important to the future of the web.
>
> 86276 split to containing block is not working for XML
> A major bug in XML-in-CSS styling.
>
> 34297 form controls with style="display: none;" unsuccessful in Mozilla
> This is another bug that keeps biting people.
>
> 72360 Crash caused by attempting to create a circular frame list in
tables
> This would block the use of CSS tables due to it crashing Mozilla.
>

> 78094 Floats Are Broken
> This is a very important CSS1 area.
>

> 97726 line-height&font-size
> Serious W3C CSS1 test suite failure.

>
> 15405 Root element is stretching vertically to fit the viewport

> Another serious CSS1 bug.
>
> 46918 line-breaking bug caused by +ve margin-right on inline elements
> 3490 line-breaking bug caused by -ve margin-right on inline elements
> A couple of serious CSS1 bugs very visible on the W3C test suite.
>

> There are plenty more important bugs -- but I'd like your help to decide
> which are the most important. Please reply to this thread (and cc me)
> giving a bug number and summary and explaining why your bug needs to be
> fixed to match the two importance criteria. (Please keep your replies to
> the n.p.mozilla.layout newsgroup.)
>

> Note that Gerv has told me that this is not a list of "blockers" -- 1.0
> might well ship with none of these bugs fixed. It's just supposed to be
> an indicator of what bugs mozilla.org would _like_ us to work on.
>

> --
> Ian Hickson
>
>

[Axel Hecht]

Jeffrey Yasskin wrote:
<...>

> Well, it would be nice if we could say XSLT was "fully supported" by 1.0.
> That may be too broad, but it's just playing catch-up with Microsoft.
>

Who said they did? Honestly, ask Jonas how much of precision, exactness,
border cases IE really handles.

Axel

<...>

[Jonas Sicking]

Yep, IE's implementation is not as conforming as they claim. For example
neither xsl:apply-imports or LRE stylesheets are implemented at all (well,
they have an implementation of LRE stylesheets, but it's basically useless).

But in all honesty, IE is more conforming then we are, but we're working on
it. Including working on a list of XSLT bugs we feel are mozilla1.0
critical.

/ Jonas Sicking

"Axel Hecht" <a...@numerik.uni-kiel.de> wrote in message
news:3BD91BC9...@numerik.uni-kiel.de...

[fantasai]

Ian Hickson wrote:
>
> Mozilla 1.0 is coming soon, and mozilla.org have asked me to try to list
> what standards compliance bugs should be highlighted in that context. As
> this is an open project, I am asking for your help in doing this.

I agree with Bernd about the CSS2 collapsed borders table model.
I think Mozilla should support rules=groups in Moz1.0, so I suggest
also bugs 24113 and 43178.
http://bugzilla.mozilla.org/show_bug.cgi?id=24113
http://bugzilla.mozilla.org/show_bug.cgi?id=43178

Standard mode table background rendering either needs to be correct or
disabled so that we don't introduce yet another incorrect rendering. At
least if we use Quirks, we're behaving the same as MSIE. (bug 4510 -
http://bugzilla.mozilla.org/show_bug.cgi?id=4510)

I'd like to see all CSS inheritance problems fixed for Moz1.0. This is
a fairly integral part of CSS--we should be able to handle it properly.
So that's bug 91054 and bug 93865 as well as 97726, which you listed.
http://bugzilla.mozilla.org/show_bug.cgi?id=91054
http://bugzilla.mozilla.org/show_bug.cgi?id=93865

Well, that's all I have in mind, particularly.