HTML comments are basically just a HTML tag that isn't rendered. Tools that 'compile' the HTML code into a document tree, including browsers, preserve comments as nodes without any extra effort.
CSS comments can go anywhere:
/*wow*/ .selector /*x*/ {animation /*z*/: 2s /*z*/ linear /*z*/ bounce;}
Tools that transform/parse CSS can either:
1. Strip comments before parsing, meaning anything based on the parsed version will lose the comments.
2. Dedicate a disproportionate amount of complexity to retaining the comments, and still not really have a good way to handle them through edits/transformations.
But if it's valid CSS it has to be representable in AST/object model? It's a comment, it can't have any child nodes, it doesn't depend on anything - pretty trivial. And if it's in the tree you can transform it with proper tools. If you are transforming CSS you have to write a proper parser and not just a bunch of regexes
EDIT: also why is it useful to have comments in the object model in the first place? To access them from js?
His podcast with Louie Mantia in July was pretty clear with it, though it also suggests why he’s given significant criticism of the design direction, but mostly just has quips and shade thrown at Alan Dye on the blog:
> I get to ask Alan Dye about [the shadows on Apple Watch faces]. And he was like, oh, we render a shadow? And I was like, oh, you never even looked. I just instantly realised he’d never really even looked at it. Like, somebody at Apple has, but Alan Dye didn't. […] It just suddenly came to me, oh, he doesn't do the job I thought he did.
Sketchfab clearly notes the original file format when you download a model, and lets you choose between it and various other converted formats. [Example: https://imgur.com/a/himJBfG ]
The entire idea that numbers would be treated on a character by character basis rather than as numbers is somewhat intuitive for developers and not for non-technical people.
The answer to all of those questions is no for lexicographic ordering. Lexicographic ordering leads to surprise and confusion as a result.
> It's like a feature request that initially sounds reasonable and useful but once you explore the requirements in detail you realize there are too many edge cases to be able to meet the request in a non-brittle way.
It's been on windows and macOS for coming up on 25 years, and is in practically every modern UI. It’s reasonable.
If you can start from any arbitrary different point, you can just start from the point you’re intending to reach, and don't need to break any other rules.
As per FIDE rule 3.10.3 "A position is illegal when it cannot have been reached by any series of legal moves". The position isn't legal per FIDE rules.
Beyond there being too many queens… black could not possibly have made the last move. For white to have any moves right now, the last move must have been black moving the king to H8. But G8, G7, H7 are all occupied, so where could the King have moved from?
Legality is a long standing term of art used by chess problem creators. Essentially it means a position withtwo kings on the board, non touching, and not both in check. And no pawns on first or eighth ranks. It has nothing to do with whether the position is reachable from standard chess rules. Along came FIDE in 1999 with its standardized nomenclature but that doesn't invalidate the terminology used by chess problem creators in their own work.
I don't think I’ve ever heard it used like that, and in trying to find any example other than the page we’re commenting on, I’ve only found counterexamples.
Whether it’s wikipedia’s 'Glossary of Chess Problems' or OzProblems or 'Sam Loyd and his chess problems' from 1913, they’re all using 'legal' as synonymous with 'reachable'.
What does making a different choice for GUI and CLI apps achieve, other than making it impossible to ever have a single coherent place to look/synchronise/etc?
XDG's spec doesn't make such a distinction, so you’re advocating for a new competing standard.
I don't think Apple’s documentation intends to cover command line programs, but… in the absence of any concrete rule, putting your files where most programs on the system do is a reasonable choice, and that place will never be ~/.config/ on macOS.
Apps like homebrew that default to the library but support XDG_CONFIG_HOME if explicitly set, are a decent compromise, though.
Control+F4 - ‘move focus to the active or next window’ is essentially that. (With the caveat that if your keyboard focus winds up on the menu bar or otherwise not on a window at all, control+f4 shifts focus back to the window, rather than switching windows. The main way to make that happen is with the other control-f-key shortcuts that no-one uses, though)
If you’re going to use it I’d probably rebind it in the keyboard shortcuts settings.
HTML comments are basically just a HTML tag that isn't rendered. Tools that 'compile' the HTML code into a document tree, including browsers, preserve comments as nodes without any extra effort.
CSS comments can go anywhere:
Tools that transform/parse CSS can either: 1. Strip comments before parsing, meaning anything based on the parsed version will lose the comments. 2. Dedicate a disproportionate amount of complexity to retaining the comments, and still not really have a good way to handle them through edits/transformations.