12400 2011-03-30 08:00:46 +0000 Inconsistent treatment of combining characters beginning text run 2015-08-23 06:58:45 +0000 1 1 1 Unclassified HTML Checker General unspecified PC Linux REOPENED https://www.w3.org/Bugs/Public/show_bug.cgi?id=13502 http://webkeys.platonix.co.il/layouts/show/system/si1452/ P2 normal --- 1 shai mike hsivonen www-validator-cvs oldest_to_newest 47048 0 973 shai 2011-03-30 08:00:46 +0000 Created attachment 973 explanation and exemplification of problem Hi, I need to present a base character with a combining character, while emphasizing the combining character and demoting the base character to "background" status. In other words, I want to present a combination with different styles for the combined parts. According to the validator, a text run should not begin with a combining character. This makes it impossible for me to get what I want, as :first-letter applies a style to the combination as a whole (obviously). I was able to "work around" the validation issue by inserting a zero-width character as first in the run, between my base character and the combining one. Since this is clearly cheating, I think the validator should have caught me. I've tested a page with the workaround (the URL for this bug) on Chrome 10, Firefox 3.6 and Internet Explorer 9. Chrome and Firefox render it the way I want, IE was confused and did not render the combining character at all. Actually, I'm not sure if this is a problem in the validator or the HTML5 spec, but I thought filing it here was a good way to push it towards the right people. 86435 1 mike 2013-04-21 01:32:44 +0000 (In reply to comment #0) > Actually, I'm not sure if this is a problem in the validator or the HTML5 > spec, > but I thought filing it here was a good way to push it towards the right > people. I believe that the validator is conforming here to the behavior required by the HTML5 spec -- or maybe by other specs that the HTML5 normatively references. I think the error message for this case is coming from the HTML parser code that the validator uses, not the validator code itself. One way you can check that is, do "View source" on your test file in Firefox, which uses the same HTML parser code as the validator. Firefox's View-source feature will mark in red any parsing problems it finds. So if you see that it's flagging the same problem that the validator is reporting, then you know it's due to that HTML parser code. And that HTML parser code attempts to conform to the HTML5 spec. So if you'd like to see a spec change around this, please consider posting the details to either public-html@w3.org or whatwg@whatwg.org 86449 2 shai 2013-04-21 06:37:24 +0000 Since this bug was filed, several things changed. One of them is the page URL (updated). Another is that the issue was discussed in #13502 (added as "see also"), where it was concluded that both the use case (a combined character with separate styling for the separate parts) and the implementation (a text run starting with a combining character) are valid; further, they have always been valid. According to comment 6 there (https://www.w3.org/Bugs/Public/show_bug.cgi?id=13502#c6), the validator's behavior is intentional and implements charmod-norm; according to the later discussion, charmod-norm does not apply to HTML. No change to the visible HTML spec was needed to fix this (charmod-norm was never referenced in the first place), but a comment to this effect was added to the document source. So -- in the first case, where text runs do begin with combining characters, the validator's behavior is not conforming to the HTML5 spec or any normative reference. In the second case, where a combining character follows a zero-width character, I'd expect a warning not because it violates a spec -- but because it makes no sense. Following the resolution of #13502, I changed the referenced web application to produce text runs that begin with combining characters, and now it gets all these warnings from the validator. Viewing the source of the page does not show the relevant characters in red -- they are all in orange (as entity references); this strengthens the claim that the warning comes from the validator and not the HTML parser. Thanks, Shai. 89911 3 mike 2013-06-26 18:11:28 +0000 (In reply to comment #2) > discussed in bug 13502, where it was concluded that both the use case (a > combined character with separate styling for the separate parts) and the > implementation (a text run starting with a combining character) are valid; > further, they have always been valid. > > According https://www.w3.org/Bugs/Public/show_bug.cgi?id=13502#c6), the > validator's behavior is intentional and implements charmod-norm; according > to the later discussion, charmod-norm does not apply to HTML. No change to > the visible HTML spec was needed to fix this (charmod-norm was never > referenced in the first place), but a comment to this effect was added > to the document source. > > So -- in the first case, where text runs do begin with combining characters, > the validator's behavior is not conforming to the HTML5 spec or any > normative reference. CCing Henri Sivonen, who's way more familiar with this than me... 89959 4 hsivonen 2013-06-27 14:28:26 +0000 Do all browsers support styling combining characters separately of the base character? 89960 5 shai 2013-06-27 14:43:37 +0000 It is currently supported badly by Firefox and Chrome (used Chromium) on Linux; I suspect it is not supported by IE, and I don't know about others (but they all use Webkit now, don't they?...) By "supported badly" I mean that applying separate styling to combining characters does render a separately styled character, but it is usually moved a little off the place it should be (less than a whole character width, but some). I wasn't able to test this much on IE, as I'm not a Windows user. In the little tests I was able to do, IE failed to display the combining characters; I can't be sure if this was a problem with the feature or a font lacking the combining characters I used (Hebrew diacritics). Also, I'm not sure the others behave the same in this respect on all platforms. 92146 6 hsivonen 2013-08-16 09:46:41 +0000 (In reply to comment #5) > It is currently supported badly by Firefox and Chrome (used Chromium) on > Linux; I suspect it is not supported by IE Sounds like this isn't interoperably supported by major browsers then! I suggest WONTFIX in the validator. 92147 7 shai 2013-08-16 10:00:30 +0000 (In reply to comment #6) > (In reply to comment #5) > > It is currently supported badly by Firefox and Chrome (used Chromium) on > > Linux; I suspect it is not supported by IE > > Sounds like this isn't interoperably supported by major browsers then! I > suggest WONTFIX in the validator. I was under the impression that the validator is supposed to express the W3 standards, not the current state of implementations. Was I wrong? 92149 8 hsivonen 2013-08-16 10:16:17 +0000 The standards should be realistic about interop. 92150 9 mike 2013-08-16 10:21:44 +0000 resolving wontfix per comment 6 92154 10 shai 2013-08-16 10:53:21 +0000 (In reply to comment #8) > The standards should be realistic about interop. Then you should change the standards, overriding the conclusion reached in ticket 13502 (and the intentions of UNICODE, as detailed there). To clarify: The problem is that the validator rejects something that the standards allow, on the ground that the browsers don't implement it well; effectively undermining the standards committees. I find this decision unreasonable. (I looked for some guidelines on whether it is OK for me to reopen a bug when I disagree with the decision, and couldn't find any; please accept my apology if this is a faux pas). 92179 11 mike 2013-08-16 17:23:34 +0000 (In reply to comment #10) > (In reply to comment #8) > > The standards should be realistic about interop. > > Then you should change the standards, overriding the conclusion reached in > ticket 13502 (and the intentions of UNICODE, as detailed there). If you want to have a change made to a particular spec, this bug is not the place to do it. > To clarify: The problem is that the validator rejects something that the > standards allow, The validator doesn't "reject" it -- it emits a warning, not an error. A warning is appropriate here, given comment 5. > on the ground that the browsers don't implement it well; The fact that browsers don't implement it well is the reason the validator is emitting a warning. The warning is there to let users know that something they might be think will work correctly actually might not work as they expect. > effectively undermining the standards committees. > > I find this decision unreasonable. > > (I looked for some guidelines on whether it is OK for me to reopen a bug > when I disagree with the decision, and couldn't find any; please accept my > apology if this is a faux pas). The reason I moved the bug to "resolved" is that in comments here you've already heard from the maintainers of the validator, neither of whom is planning to take any action on the bug. 92220 12 shai 2013-08-17 06:55:35 +0000 (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #8) > > > The standards should be realistic about interop. > > > > Then you should change the standards, overriding the conclusion reached in > > ticket 13502 (and the intentions of UNICODE, as detailed there). > > If you want to have a change made to a particular spec, this bug is not the > place to do it. > It was Henri who suggested there was something wrong with the spec. I would like to see it implemented as it stands. > > To clarify: The problem is that the validator rejects something that the > > standards allow, > > The validator doesn't "reject" it -- it emits a warning, not an error. A > warning is appropriate here, given comment 5. > > > on the ground that the browsers don't implement it well; > > The fact that browsers don't implement it well is the reason the validator > is emitting a warning. The warning is there to let users know that something > they might be think will work correctly actually might not work as they > expect. > I see. In that case, perhaps the warning message can be made clearer. > > The reason I moved the bug to "resolved" is that in comments here you've > already heard from the maintainers of the validator, neither of whom is > planning to take any action on the bug. Will you accept a patch to this effect (make it clearer that the warning is about current implementation in browsers)? 92222 13 mike 2013-08-17 13:03:53 +0000 (In reply to comment #12) > > If you want to have a change made to a particular spec, this bug is not the > > place to do it. > > It was Henri who suggested there was something wrong with the spec. I would > like to see it implemented as it stands. So then I guess what you should probably do is file bugs in the Mozilla, Chrome, and WebKit bug trackers at least. > > The fact that browsers don't implement it well is the reason the validator > > is emitting a warning. The warning is there to let users know that something > > they might be think will work correctly actually might not work as they > > expect. > > I see. In that case, perhaps the warning message can be made clearer. Yeah, maybe so. > > The reason I moved the bug to "resolved" is that in comments here you've > > already heard from the maintainers of the validator, neither of whom is > > planning to take any action on the bug. > > Will you accept a patch to this effect (make it clearer that the warning is > about current implementation in browsers)? We'll review any patch submitted and if it's an improvement, it'll likely end up getting checked in. But if you have some suggestion for improved wording, you can just post it here and we can see if Henri's agreeable to it and go from there. 93352 14 shai 2013-09-13 14:15:26 +0000 Chromium bug: https://code.google.com/p/chromium/issues/detail?id=290906 Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=916102 Thanks for the suggestions. For the improved text: Instead of the current "Text run starts with a composing character.", how about: "Separate styling for composing characters is not supported well by current browsers. If no separate styling is intended, avoid starting text runs with composing characters." (in case this "standard but not supported well" is the whole sense of warnings, then perhaps this is not the place to add it, but in a more general place in the validator output). Thanks again, Shai. 973 2011-03-30 08:00:46 +0000 2011-03-30 08:00:46 +0000 explanation and exemplification of problem test-first.html text/html 1593 shai PERPQ1RZUEUgaHRtbD4KPGh0bWw+CjxoZWFkPgo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPgogLmRk ZCB7IGZvbnQtd2VpZ2h0OiBib2xkOyBjb2xvcjogcmVkOyB9CiAuZGRkIHNwYW4geyBmb250LXdl aWdodDogbm9ybWFsOyBjb2xvcjogYmxhY2s7IG9wYWNpdHk6IDAuMjU7IH0KIC5kZGQgeyBmb250 LWZhbWlseTogZXpyYSBzaWwsIHZlcmRhbmE7IH0KIC5lZWUgeyBmb250LXdlaWdodDogYm9sZDsg Y29sb3I6IHJlZDsgfQogLmVlZTpmaXJzdC1sZXR0ZXIgeyBmb250LXdlaWdodDogbm9ybWFsOyBj b2xvcjogYmxhY2s7IG9wYWNpdHk6IDAuMjU7IH0KIC5lZWUgeyBmb250LWZhbWlseTogZXpyYSBz aWwsIHZlcmRhbmE7IH0KPC9zdHlsZT4KPC9oZWFkPgo8Ym9keT4KPHA+SGksCgo8cD5JIG5lZWQg dG8gcHJlc2VudCBhIGJhc2UgY2hhcmFjdGVyIHdpdGggYSBjb21iaW5pbmcgY2hhcmFjdGVyLAp3 aGlsZSBlbXBoYXNpemluZyB0aGUgY29tYmluaW5nIGNoYXJhY3RlciBhbmQgZGVtb3RpbmcgdGhl IGJhc2UKY2hhcmFjdGVyIHRvICJiYWNrZ3JvdW5kIiBzdGF0dXMuIEluIG90aGVyIHdvcmRzLCBJ IHdhbnQgdG8gcHJlc2VudAphIGNvbWJpbmF0aW9uIHdpdGggZGlmZmVyZW50IHN0eWxlcyBmb3Ig dGhlIGNvbWJpbmVkIHBhcnRzLgoKPHA+QWNjb3JkaW5nIHRvIHRoZSB2YWxpZGF0b3IsIGEgdGV4 dCBydW4gc2hvdWxkIG5vdCBiZWdpbiB3aXRoIGEgY29tYmluaW5nCmNoYXJhY3Rlci4gVGhpcyBt YWtlcyBpdCBpbXBvc3NpYmxlIGZvciBtZSB0byBnZXQgd2hhdCBJIHdhbnQsIGFzCjpmaXJzdC1s ZXR0ZXIgYXBwbGllcyBhIHN0eWxlIHRvIHRoZSBjb21iaW5hdGlvbiBhcyBhIHdob2xlIChvYnZp b3VzbHkpLgoKPHA+SSB3YXMgYWJsZSB0byAid29yayBhcm91bmQiIHRoZSB2YWxpZGF0aW9uIGlz c3VlIGJ5IGluc2VydGluZyBhCnplcm8td2lkdGggY2hhcmFjdGVyIGFzIGZpcnN0IGluIHRoZSBy dW4sIGJldHdlZW4gbXkgYmFzZSBjaGFyYWN0ZXIKYW5kIHRoZSBjb21iaW5pbmcgb25lLiBTaW5j ZSB0aGlzIGlzIGNsZWFybHkgY2hlYXRpbmcsIEkgdGhpbmsKdGhlIHZhbGlkYXRvciBzaG91bGQg aGF2ZSBjYXVnaHQgbWUuCgo8cD5JJ3ZlIHRlc3RlZCBhIHBhZ2Ugd2l0aCB0aGUgd29ya2Fyb3Vu ZCBvbiBDaHJvbWUgMTAsIEZpcmVmb3ggMy42IGFuZApJbnRlcm5ldCBFeHBsb3JlciA5LiBDaHJv bWUgYW5kIEZpcmVmb3ggcmVuZGVyIGl0IHRoZSB3YXkgSSB3YW50LCBJRQp3YXMgY29uZnVzZWQg YW5kIGRpZCBub3QgcmVuZGVyIHRoZSBjb21iaW5pbmcgY2hhcmFjdGVyIGF0IGFsbC4KCjxoMT4g VGhpcyBwYXNzZXMgdmFsaWRhdGlvbjwvaDE+CjxoMiBjbGFzcz0iZGRkIj48c3Bhbj4mI3gwNWRl Ozwvc3Bhbj4mcmxtOyYjeDA1OTI7PC9oMj4KCjxoMT4gVGhpcyBlcXVpdmFsZW50IGZhaWxzIHZh bGlkYXRpb248L2gxPgo8aDIgY2xhc3M9ImRkZCI+PHNwYW4+JiN4MDVkZTs8L3NwYW4+JiN4MDU5 Mjs8L2gyPgoKPGgxPiA6Zmlyc3QtbGV0dGVyIGRvZXMgbm90IGRvIHdoYXQgSSB3YW50PC9oMT4K PGgyIGNsYXNzPSJlZWUiPiYjeDA1ZGU7JiN4MDU5Mjs8L2gyPgo8L2JvZHk+CjwvaHRtbD4K