Open matkoniecz opened 9 years ago
Yes - I just noticed this in a patch that was putting marker-clip: false
before marker-fill
. I think having a preferred order to our attributes would help but I don't want to make it even harder to contribute.
I think that the best way to solve this would be using/creating parser that would consume CartoCSS and output it in the format that we would want.
I'm not sure what you mean with this - don't we especially want to have a fixed order in the code that is actually being edited? For carto, it doesn't matter what order the code is in.
code that is actually being edited
New code* would replace old one - and would become one that is edited by contributors.
*equivalent to old one but with consistent order of the attributes per selector
Ah, thought you were talking about some kind of preprocessor.
I don't think the problem is big enough to write a parser for it, but if you feel like it, feel free to...
@matkoniecz Is this issue up to date? If not, please close.
Feel free to check and report whatever "text-size is now defined sometimes before text-fill, sometimes after" is still true.
You raised this issue, not me...
And AFAIK nobody fixed it.
As in - text-size is now defined sometimes before text-fill, sometimes after. It should be consistent and "put the 'more important' things first, so what is going to be rendered (e.g. text-name) comes before the fiddly details of getting it to look right (text-halo-radius)".
I think that the best way to solve this would be using/creating parser that would consume CartoCSS and output it in the format that we would want.
It would be less tedious and allow easier adding new rules how CartoCSS defitions should be formed than manual moving of lines.
It was part of #710 - but it is a more general issue.