Consider making convertStringIndex in CssParser.jj not mangle string literals

[sideshowbarker]

Given invalid input such as the following:

a { font-size: foo\7bar; }
b { font-size: foo\7; }

…the CSS checker reports:

Value Error : font-size foo\0007bar is not a font-size value : foo\0007bar
Value Error : font-size foo\000007 is not a font-size value : foo\000007

I have no idea why for the\7 literal from the input, there’s a difference in what the checker changes it to — in the first case, \0007 (padded with 3 zeroes), while in the second, \000007 (five zeroes)…

But regardless, I don’t understand why it’s changing that literal from the input to begin with. It’s unclear to me why it should need to be touching it all.

Anyway, the code that causes it is around here:

css-validator/org/w3c/css/parser/analyzer/CssParser.jj

Lines 2869 to 2879 in 9e798fd

	switch (c) {
	case '0': case '1': case '2': case '3': case '4':
	case '5': case '6': case '7': case '8': case '9':
	case 'a': case 'b': case 'c': case 'd': case 'e': case 'f':
	case 'A': case 'B': case 'C': case 'D': case 'E': case 'F':
	int numValue = Character.digit(c, 16);
	int count = 1;
	if (maxCount == 0) {
	maxCount = ((ac.getCssVersion() == CssVersion.CSS1) ?
	4 : 6);
	}

That code has been in the source since it was first checked into version control, nearly 15 years ago. So maybe the only person who might still understand the intent of it is @plehegar.