It would be nice to support the CSS attributes word-spacing and letter-spacing. Although I would have to say I would put them among the lowest priorities in CSS1, I think they are still definitely worth implementing, especially if you want to claim complete CSS1 support.‰

We now support them fully; however, the spec is unclear about how some aspects should be handled so don't go nuts if it renders oddly; the implementation will be updated when our css guy gets clarification back from the working group. I'm reassigning this to peter so that he can assign it back once the clarification has arrived.

Last I heard from the CSS list, the clarification was that the value of this property is the delta to the default value. In other words, if default letter spacing is 0.1em, and the author says letter-spacing: -0.1em, the total letter spacing applied should be 0.0em, not -0.1em. I thought this was extremely counterintuitive, but it's what the CSS gods said.

Actually, the latest clarification from the CSS w/g is that _I_ write up a proposal to define the normative behavior, since the spec doesn't. Expect something next week.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Isn't this resolved now??? The last relevant comment is from six months ago!

Pushing off non-beta 1 issues

Reassigning peterl's bugs to myself.

Accepting peterl's bugs that have a Target Milestone

My opinion is that the default value of 'word-spacing' (i.e., 'normal') should *not* be equivalent to 0 (and 0 should mean that "a bc" and "abc" should look the same), while the default value of 'letter-spacing' (again, 'normal') *should* be equivalent to 0 (since you don't adjust letter spacing for justification). I think this can (mostly) be implied from CSS1.

Pushing my M15 bugs to M16

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...

Letterspacing is defined as space between characters, but that doesn't include spaces, does it? Currently, letterspacing is (effectively) added to the space between words. Also, trailing letterspacing affects whether a word fits on a line and the width of a line. IMO, this should not be so. (See attachment.)

non-essential for m16

I've asked dbaron to research what the "Right Thing" really is for this bug. Once we know that, we can figure out what to do for FCS.

This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

Marking nsbeta3 for tracking. Recc. nsbeta3+. This is a CSS1 W3C Official Test Suite bug. Have asked dbaron to investigate this issue and try to determine what the Right Thing is, then we need to see if we can do it.

The above testcase (which shows that we are doing deltas from normal, rather than values, which I don't like but is what the spec says), along with: http://www.w3.org/Style/CSS/Test/current/sec541.htm http://www.w3.org/Style/CSS/Test/current/sec542.htm show that our behavior is correct except possibly for the issue mentioned by fantasai@escape.com above. I will raise this on www-style.

I take that back. I think the remaining issues are the following: * How does 'letter-spacing' apply at word gaps? Should it: + not apply + apply once + apply twice (once on each side of space) * What happens where 'letter-spacing' and 'word-spacing' change? Should it work like collapsed margins, as Matthew Brealey proposed in http://lists.w3.org/Archives/Public/www-style/1999Nov/0237.html ? Do we care?

We should apply letter-spacing twice at word-gaps like MacIE5 does. It preserves the legibility of the text when letter-spacing becomes larger than the normal word-spacing. In the 2 lines below, letter-spacing is 3 times the width of the space. In the first line, it is applied once between words; in the second one, it is applied twice. g a p s a r e n o t v i s i b l e g a p s a r e v i s i b l e Reassigned to erik who is taking care of Text Layout. Changed the summary line to "letter-spacing should apply on space characters too". Reset the milestone from "future" to M20 because of nsbeta3 nomination.

correctness of compliance with official W3C CSS1 test suite. Passing this is a key product goal. Test suite results will be closely watched by reviewers. Please approve for nsbeta3.

mark nsbeta3+ P2 per bug meeting (ekrock)

Marking M18 because it's been approved for beta3

Adding buster to cc: list.

mark it as P4. shanjian, can you help to look at this bug ?

Marking [nsbeta3-] and Future because Netscape engineering is overburdened. Letter spacing on space characters is frankly a rather obscure issue. Will document this as a known issue in release notes. Please feel free to note your concerns or objections, but please don't clear nsbeta3- unless you are committing to accept the bug and implement the fix yourself in the nsbeta3 timeframe.

For the record, letter-spacing on space characters isn't an obscure issue. It makes letter-spacing look horrible on any multi-word text. The workaround is to use word-spacing, but then once the bug is fixed it will look horrible on any pages with that workaround.

Possible hack workaround I thought of: since letter spacing on characters works but space characters doesn't, if you want to create the visual appearance of spaces but have letter spacing work correctly, simulate spaces by surrounding a non-space character (e.g. an "a" or an "m" or a "_" or something) with a SPAN and set STYLE="visibility:hidden" on the SPAN. If the enclosure within the SPAN doesn't change how spacing is calculated, that ought to work both in the initial release with the bug and future releases without it. If anyone has a second to test this and confirm this idea that would be great!

That workaround won't work on any browsers that don't support CSS2's visibility property. We also shouldn't expect authors to do things that messy.

This bug basically kills 'letter-spacing' for multi-word spans. I would recommend removing support for this property altogether if we do not fix it. If nothing is done then: RELEASE NOTE ITEM: Netscape 6 does not support the CSS 'letter-spacing' property correctly when applied to spaces. Work around: Do not use 'letter-spacing' to affect any multi-word phrases in any of your documents until such time as Netscape 6 is no longer in use (probably some time in 2004).

No, documentation group, do *not* put the above text into the release notes, it's a complete overreaction. We should document the problem and my hack workaround instead. See me for details; I'll supply appropriate text. Ian: I applaud your passion for standards compliance, but let's please try to keep things in proper perspective. The tone of that proposed text was simply inappropriate for release notes. We're talking about a problem with *spacing* for the first release; the text can still be read. If authors are really steamed about this, they can client-sniff and tell folks to upgrade to Netscape 6.0x or 6.x that fixes this or to use IE. This bug is *nothing* like the Nav4 CSS1 *crash* bugs that so hampered adoption of CSS on the web. Is the glass 0.5% empty or 99.5% full? And does any other browser support this many standards this deeply simultaneously across platforms? No. It is not the few-and-far-between flaws in standards compliance of Netscape 6 that will be holding back the usability of standards; it is overwhelmingly the yawning holes of IE5.5 Win and IE5 Mac. David: Since Nav4+ and IE4+ and Opera 4+ support visibility, that covers the overwhelming majority of current browser users. They can use the workaround, accept the bug in the first release, or not use the feature; their call.

I agree with Ian's proposal. Eric's workaround is inappropriate and will mess up lots of other user-agents (for example, non-CSS browsers, browsers with CSS or author styles turned off, CSS1 browsers that don't support CSS2's visibility property, search engines, etc.).

Reassigned to myself, I have a fix: Index: nsTextFrame.cpp =================================================================== RCS file: /m/pub/mozilla/layout/html/base/src/nsTextFrame.cpp,v retrieving revision 1.276 diff -r1.276 nsTextFrame.cpp 543a544,545 > mWordSpacing += mLetterSpacing; // bug 1046 >

looks fine, a=buster

Thank God, a fix! (Actually, thank Pierre! ;-> ) I strongly endorse for RTM. Note that this is extremely high profile standards compliance. It's a test where Gecko is failing and IE5 Mac is succeeding on the W3C CSS1 Standards Compliance test suite--the only standard for which an official W3C-blessed test suite exists. David, Ian: to help us make the case to PDT, would you please summarize as a list of bullet points the impact of *not* accepting this fix? Points to note: retard ability of content developers to use feature going forward, the fact that workarounds won't then be forwardly compatible with a fixed version, accessibility, etc. Pierre: am I right in thinking that this fix is very low-risk?

Thanks Pierre. PDT: Eric summmed it up quite well. * High profile CSS1 test suite bug. * Relatively low risk (one line fix) * Improves readability/accessibility of any page using this property * Bug would cause headaches for any web author trying to migrate to CSS * No usable workaround exists I t m a k e s t h e d i f f e r e n c e b e t w e e n t e x t s p a c e d l i k e t h i s a n d t e x t s p a c e d l i k e t h i s.

Looks good to me to. r=erik

Adding rtm+. This is css1 compliance and low risk.

Marking rtm++. Let's get this one checked into the branch.

Fix checked in nsTextFrame.cpp (trunk + Netscape_20000922_BRANCH).

Using Pierre's 6/16 textcase, verified fixed on Win, Mac and Linux with 10_11 branch build. Added vtrunk keyword.

This testcase seems to be fine for Mozilla win32 and Mac builds on the trunk (101704) but it fails for me on trunk (101708) and trunk (101712) linux builds.

The testcase worksforme with the 10/31 Linux trunk build.

Marking verified as it has been tested successfully for fix on branch and trunk builds across platform