Closed DoctorGester closed 7 years ago
@/ TEST / "works" meaning it will silently ignore any CSS below that line.
Spent 3 hours on this today. ;) Thanks for figuring it out Doc.
/** Okay */
/* Okay */
/** Bad **/
/* Bad **/
/***/ (Bad)
/**/ (Okay)
// Okay (Although not standard CSS syntax, Dota's parser is okay with this.)
/*** Okay ***/
/**** Bad ****/
/***** Okay *****/
/****** Bad ******/
These last ones are just amusing. Looks like *closing* comments with an even number of stars kills it.
Edit: Emphasis on silently.
Doc mentioned a "couldn't parse" error, but I don't see any errors on my console when the css is purged using the /** Bad Comment **/
type comment.
[ AssetSystem ]: Reloading Resource [1/1]: panorama/styles/custom_game/boss/boss.vcss
[ AssetSystem ]: On-demand recompile of asset panorama/styles/custom_game/boss/boss.vcss
[ AssetSystem ]: -> reason: At least one out-of-date dependency: panorama/styles/custom_game/boss/boss.css (file CRC changed)
[ AssetSystem ]: Recompiling resource asset: 'panorama/styles/custom_game/boss/boss.vcss'
[ ResourceCompilerSystem ]: - dota_addons\single_fight\panorama\styles\custom_game\boss\boss.css
[ AssetSystem ]: Flushing persistent asset info to disk, 324.098 seconds since last, 1000 change delta
[ AssetSystem ]: AssetSystem saved persistent info for 1 layers / 351 assets in 0.013 sec
[ AssetSystem ]: Reloading Resource [1/1]: panorama/styles/custom_game/boss/boss.vcss
It just happily reloads the CSS, and all styles below the comment are silently ignored.
This has been the case since forever, but I always thought about it as a worthily trade-of for the convenience that // offers. I usually place an ascii-art logo in stuff I do so that's how I first bumped into it.
Valve only uses /* */
or 3-line blocks with /* ------ */
in their code, tough.
And just to add to this, xml parser also borks comments ( something about dashes and spaces, don't remember exactly but it's clearly not in the drafts).
I'm surprised the whole thing works when code written by Valve developers comes up with such huge (white)space inconsistencies that a basic higher-level editor with syntax highlighting would reveal on the spot. I guess it's edited remotely from a phone with a basic notepad-like editor :)
The latest update should have fixed this.
Confirming, looks fixed, thanks!
Well, the xml comment parsing is still broken.
Broken 1:<!---Nav Bar--->
Broken 2:<!-- Nav Bar -- -->
Only the strict form works: <!-- Nav Bar -->
Probably the same weird tokenizer as it was in css.
This issue was about CSS comments. You should make a new issue for XML comments
It's (probably) the same tokenizer, as the xml can bundle css too, so there is no harm in commenting about it here.
That means putting
/***/
in a file gives semi-random results, completely deleting some of the styles, does not always cause parsing errors./* TEST **/
work too, as does/** TEST **/