[HN Gopher] When or If
___________________________________________________________________
When or If
Author : todsacerdoti
Score : 80 points
Date : 2022-03-14 16:21 UTC (6 hours ago)
(HTM) web link (meyerweb.com)
(TXT) w3m dump (meyerweb.com)
| joemi wrote:
| I don't think the CSSWG should care one bit about Sass's syntax.
| Just use if...else if that's what makes sense (and I think it
| does make sense). Sass is interpreted into CSS, so CSS is the
| authoritative language, and Sass is a derivative.
| silvestrov wrote:
| Yes, sass should change now that css will support conditionals.
|
| sass stepped on css' toes by reusing the @xxx syntax from css
| instead of creating their own syntax.
| systemvoltage wrote:
| Sass should just have been a python (or your fav lang)
| library. Express the entire CSS as objects and then finally
| compile it. There was no need for yet another DSL. DSLs seems
| like the easy way out but it puts a lot of burden for users
| to learn it. It is pretty compact and clean though. So
| there's that.
| munk-a wrote:
| > sass stepped on css' toes by reusing the @xxx syntax from
| css instead of creating their own syntax.
|
| Yes and no - they're accepting that there may be future
| compatibility breaks (like this very case) but using some
| arbitrary other glyph as a marker is also dangerous. Whenever
| you're working on a second layer tool you're limited in how
| much future compatibility you can guarantee (and the limit is
| 0).
| kazinator wrote:
| A given piece of working SASS never has to have a
| compatibility issue, because it's processed through SASS
| and the SASS goes away. (Only some backward-incompatible
| upgrade to SASS can break the code.) The fact that CSS
| evolves to introduce constructs that look exactly like SASS
| doesn't in and of itself break anything from the point of
| view of the old code which doesn't use those new CSS
| constructs.
|
| SASS code is written in the SASS language, with CSS as a
| back-end; the only thing that can break a piece of existing
| SASS code (in terms of making it either fail to generate,
| or generate different CSS) is a backwards-incompatible
| upgrade to the SASS processor. For instance, someone has
| SASS code which relies on certain @-things to be passed
| through to CSS, but an upgrade to SASS claims some of them
| for itself.
|
| (A change in CSS could break the generated CSS code, which
| is a different issue.)
| timwis wrote:
| Oooh, fascinating. If I recall correctly, this happened once
| before in JavaScript. One of the Array.prototype methods has an
| unintuitive name because dojo, a very popular utility library at
| the time, monkeypatched the Array object with the method name
| they would have chose, and adding it to ECMAscript would have
| "broken the web" because so many sites used dojo.
|
| Anyone remember the method name?
| keb_ wrote:
| Not sure of the dojo conflict, but I did see this article
| recently that I thought was interesting:
| https://2ality.com/2022/03/naming-conflicts.html
| timwis wrote:
| Ah, it was MooTools, not dojo! It's the examples cited in
| that article (e.g. String.prototype.contains()). Thanks!
| croes wrote:
| And now MooTools is obsolete and people wonder why certain
| methods have strange names. An example of the tail wagging
| the dog.
| seba_dos1 wrote:
| I'm not sure whether arguments about other programming languages
| are relevant - most of those aren't declarative style sheets that
| operate under changing conditions. @when block may suddenly start
| to apply when the user resizes browser window, that name isn't as
| awkward as it may seem without context.
| qrian wrote:
| Another case where 3rd party tools collided with the proposed
| standard name:
| https://developers.google.com/web/updates/2018/03/smooshgate
| jdeisenberg wrote:
| Adding to the mix: `when` is used for "guard clauses" in pattern
| matching in Ocaml, Erlang, and Elixir, so it's not entirely
| unheard-of in programming languages.
| latchkey wrote:
| This is how we ended up with elif.
|
| https://twitter.com/secretGeek/status/7269997868
| abdusco wrote:
| I might be misremembering, but I thought it was to keep it 4
| chars, so that it aligns with `else` if ...:
| # ... elif ...: # ... else:
| # ...
| munificent wrote:
| No, `elif`, `elsif`, and `elseif` exist to solve a real
| grammatical problem. They occur in languages that don't have an
| explicit block statement with its own delimiters and instead
| allow a sequence of statements directly inside the then and
| else branches of an if statement, with some terminator like
| `end` at the end (or dedent in Python).
|
| In those languages, without something like `elif`, you get an
| endless march to the right when you chain a series of ifs:
| if c1 then s1 else if c2 then
| s2 else if c3 then s3
| else if c4 then s4
| else s5 end end
| end end
|
| C doesn't need this because it only allows a single statement
| for the then and else branches, and `{ ... }` is a statement.
| Therefore, you can chain its directly by having the else
| statement be an if statement.
| latchkey wrote:
| Certainly true. I was more making a bit of a joke about
| naming things though since that was kind of the OPs original
| point (which was subtle hinted via the twitter link).
|
| Thanks for Dart, absolutely lovely language.
| xigoi wrote:
| You could make `else if` a special sequence of tokens that
| works like `elif`.
| harryvederci wrote:
| > _nobody_ wants to have to type @conditional and @otherwise, so
| the WG went in search of shorter names.
|
| I guess nobody in the working group uses an editor with tab
| completion? Unless you're going to be writing CSS on a
| whiteboard, this seems like a non-issue to me.
| rvieira wrote:
| A bit unrelated, but I was immediately reminded of a Marcus
| Brigstocke story from when (if?) he travelled to Svalbard.
|
| > We had our safety briefing last night - all pretty obvious
| advice like "don't fall in the sea, it's cold". I wrote that one
| down.
|
| > Barbara, our second skipper, is Dutch so the word for "if" is
| the same as "when". "When the boat catches fire" was not exactly
| reassuring and "when we turn over in a big wave" even less so.
| hackerbee wrote:
| The distinction between when ("wanneer") and if ("als") is
| there in Dutch, just like in English.
| bena wrote:
| Isn't this just the ecosystem problem/paradox again?
|
| "If you're product exists to correct a deficiency in some other
| product, don't be surprised when that product makes your product
| native functionality."
|
| If CSS chooses "if", it's up to Sass to deal with that. What Sass
| uses shouldn't be a concern for CSS.
| not-my-account wrote:
| Maybe I misunderstand sass, but wouldn't they be able to just
| remove their specific "if" implementation and just allow sass
| users to use the CSS "if" implementation?
|
| Will the two "if" implementations have dramatic differences in
| how they act?
| dgb23 wrote:
| I assume the CSS if is not a compile time construct.
| genezeta wrote:
| There are indeed significant differences.
|
| The main one is that Sass is, basically, a "code generator".
| It's a sort of template language that generates CSS code. And
| so, a "Sass-if" works at code generation time, that is, when
| you execute the Sass command: sass-if (some
| logical condition) { <some CSS code> } else
| { <some other CSS code> }
|
| Depending on the condition and at compile time, sass would spit
| out the first block of code _or_ the second. The condition is,
| basically, a calculated expression that applies to values and
| variables available at compile time.
|
| Then -after deployment and when a client visits your website-
| that CSS code is served to the client. Clients are varied and
| so CSS wants to have its own _if_ structure that applies _at
| runtime_. The conditions generally would check the current
| runtime conditions (i.e. is this running on a large screen? is
| this browser in vertical orientation? etc)
| css-if (some condition pertaining this specific current
| browser) { <some CSS code> } else {
| <some other CSS code> }
|
| So, yes, they are clearly and necessarily different, both in
| scope and usage. And so you'd generally need both _if_ because
| they do different things. And that where the problem arises,
| because if you want to have both, their syntaxes need to be
| distinguishable.
| veidelis wrote:
| Very good description, thank you.
|
| One thing I don't understand is why not: 1) change Sass
| implementation to support "sass-if" and backport these
| changes to some older versions if necessary 2) upgrade the
| Sass's version and do a mass replace which sounds kind-of
| simple 3) use CSS's if happily
| genezeta wrote:
| Yeah, _personally_ that 's the option I would choose too.
| It should fall on Sass to change whatever they may need to.
|
| It's not completely "kind-of simple" though, as there is,
| potentially, a fair amount of code written with Sass in
| currently running projects. It is a cost to consider.
|
| Also, there have been some precedents in the JavaScript
| community, mainly with Mootools -an old library, mostly
| irrelevant today but with some existing code still running
| in the wild- and the name of a couple of methods such as
| _includes_ and _flatten_. The thing is that TC39 really
| pushes for "not breaking anything at all", and by
| proximity the CSS community seems to have some people with
| a similar opinion.
| kazinator wrote:
| @case { supports(display: grid) and media(min-width:
| 33em) { } otherthing(arg:
| whatever) { } otherwise {
| } }
|
| You're welcome.
| munk-a wrote:
| Are @switch, @case and @default available? Because that'd be
| even more in line with general programming language knowledge.
| kazinator wrote:
| Note that you don't need any @ sigil inside this @case
| because it contains _condition { CSS }_ pairs; where
| something like "default" or "otherwise" can be recognized as
| a special condition word without a sigil. Selectors do not
| appear there; "otherwise" isn't syntactically a selector for
| some <otherwise> tag.
|
| I got it down to one @ sygil to write a long conditional
| ladder with any number of conditions and a default.
|
| It could be called @cond, in the Lisp style; not a lot of
| people know that though.
|
| The first condition that is true fires; the rest are then
| ignored, so the order of the cases matters. Many languages
| call that sort of thing using "case" terminology.
|
| Probably a diagnostic in the browser console is worthwhile if
| the always true "otherwise" condition is followed by
| anything.
| croes wrote:
| Reminds me of https://news.ycombinator.com/item?id=25406211
| wlib wrote:
| I initially thought that "if" should be the obvious choice,
| ignoring sass entirely. However, it's clear that "when" makes
| more sense than "if" given CSS's interpretation anyways. "if"
| sort of implies a more "one-time" use like in a template/macro or
| preprocesser. "when" really captures the temporal invariance of
| CSS's conditionals.
| munk-a wrote:
| I think it's fair to acknowledge the clash, but "if" is our
| word for that thing - "when" could have been that word - every
| time you do a conditional jump you're only doing it when
| certain conditions are met "when x > 5 { y += 3; } elsewise { y
| -= 1; }" that reads perfectly fine - but it's common convention
| to use "if" for this condition.
|
| I don't really have a strong opinion on the when vs. if fight
| w.r.t. yielding support to SASS but I think that "if" is just a
| better keyword to use in this instance based on language usage
| alone.
| twiss wrote:
| I think the difference is that, if x later becomes > 5, y
| doesn't suddenly get increased by 3.
|
| By contrast, in CSS, if the condition later becomes true, the
| declarations in it _do_ start to apply. So I also think
| "when" (in the sense of "whenever") makes more sense than
| "if".
| munk-a wrote:
| CSS is evaluated (probably) in some sort of event loop in
| the browser - you can also evaluate the code I included
| above in an event loop - there is nothing inherently
| instantaneous or continuous about CSS and, given that it is
| deterministic, it's only actually recalculated on certain
| event triggers.
| runarberg wrote:
| Wasn't there such ambiguity once in Less with the calc function.
| When both Less and CSS supported their own version of calc() and
| Less would sometimes actually attempt to compute what was in the
| calc function instead of just leaving it for CSS to handle, and
| sometimes it wouldn't.
| whoisjuan wrote:
| As an adverb `when` is used mostly to refer to a time or moment.
| So semantically speaking `when` should be reserved for time
| conditionals only.
| blowski wrote:
| _When_ browser developers start caring about the semantics of
| one version of English grammar, then we'll have a lot of other
| work to do.
| weinzierl wrote:
| Not a native English speaker, but I learnt that _if_ and _when_
| have different meaning and also to translate them to different,
| non-interchangable words in my mother tongue. The Cambridge
| dictionary seems to support that view:
|
| _" We use if to introduce a possible or unreal situation or
| condition. We use when to refer to the time of a future situation
| or condition that we are certain of."_[1]
|
| Could you really replace the _if_ as used in a programming
| language context with _when_?
|
| To me, _when_ doesn 't make sense in that context at all, but
| again, English is not my first language.
|
| [1] https://dictionary.cambridge.org/grammar/british-
| grammar/if-...
| dcminter wrote:
| As a native English speaker I'd say that's spot on. In
| particular, at least in British English, 'when' is never paired
| with 'else' - you might instead pair 'until' and 'when' and I
| suppose one could contort oneself into making a case for those
| keywords to create havoc!
| noneeeed wrote:
| Also a native english speaker.
|
| I was about to disagree with you, that we use "when" when
| several things might be true, but then I realised that in
| those cases each of the possibilities _will_ happen, but at
| different times, like "when the light is read you stop, when
| it is green you go".
|
| It's fascinating how many quite subtle rules you internalise
| about your native language without realising it.
| bena wrote:
| It's kind of interchangeable if you consider not a single
| execution of your program/method, but _every_ execution of your
| program /method.
|
| When you run it with "this" value, it'll do "this". When you
| run it with "that" value, it'll do "that". Because, eventually,
| all code paths will be run.
|
| It would also be semantically valid to say: When you execute
| this program/method, if the value is "this", do "this".
|
| At the end of the day, English rules are more what we like to
| call guidelines.
| weinzierl wrote:
| That makes sense indeed. I think what you described is the
| declarative viewpoint whereas I was thinking strictly
| imperative, where we are talking about a decision in one
| particular moment.
|
| > _At the end of the day, English rules are more what we like
| to call guidelines._
|
| Tell that to my English teacher;-)
| slaymaker1907 wrote:
| Fun fact: when and if have two completely different meanings in
| Yu-Gi-Oh. "When" means that an effect has to happen precisely
| after the trigger (so if some other mandatory effect happens in
| between, the "when" effect doesn't happen). "If" is much more
| flexible and just has to be on the same stack as the triggering
| effect.
| mmcdermott wrote:
| Do other tabletop games use different definitions? I ask
| because I've always assumed this to be the operative
| distinction when reading rule books, but, come to think of it,
| I can't necessarily defend that assumption.
| bena wrote:
| Semantically, "when" and "if" describe different modes of
| thought even in everyday English.
|
| "When" usually describes an event that is likely to happen in
| some future time. "If" describes something that may or may
| not be true.
| tolmasky wrote:
| Allow me to recommend "perchance", to make it sound extra fancy:
| @perchance supports(display: grid) as-well-as media(min-width:
| 33em), @why-then-of-course: { }
| @on-the-other-hand { }
|
| Seems obvious, really.
| projektfu wrote:
| @perchance ... @thusly {} @contrarily {}
|
| :)
| abdusco wrote:
| Reminds me of the "essays" I wrote in English
| classes/technical reports. Full of fluff and no substance,
| just to sound fancy.
|
| It took me a while to learn that writing is not just putting
| words together and filling the page, but actually to tell
| something, to convey an argument. That meant learning to get
| rid of all unnecessary conjunctions and keeping it simple and
| clear.
| blowski wrote:
| We could even - shock horror - use a non-English word like `si`
| or `kama`.
| hammock wrote:
| What about "while"?
| readthenotes1 wrote:
| Better than @when...
| https://dictionary.cambridge.org/us/grammar/british-grammar/...
| rbonvall wrote:
| There is a precedent for this: British PHP.
|
| https://aloneonahill.com/blog/if-php-were-british/
| dmitriid wrote:
| > currently debating what to name a conditional structure, and
| it's kind of fascinating
|
| What's also fascinating (or, rather, horrifying) is how bad the
| whole thing is.
|
| SASS is _15 years_ this year. Its concepts have proven their
| worth over, and over, and over again (and reimplemented several
| times in Less, PostCSS plugins etc.). W3C 's own design system
| uses SASS [1]. How much of that did we get to see in CSS in the
| past 15 years? Maybe, just maybe we'll finally get nesting some
| time in the next 10 years or so.
|
| Conditionals? Hahaha. If you're betting on getting them sometime
| before 2045, you're a fool.
|
| The same thing repeats all across other tech in browsers.
| Detecting ambient light in browsers? Oh, w3c got you fam [2].
| Providing usable styleable common components? Ahahahaha, even w3c
| relies on third-party implementations [3].
|
| Most of the people on these committees have never developed a
| website in their life. Those that did only maybe implemented a
| blog or two a few decades ago. And the rest of browser
| implementors? Oh, they've never touched anything beyond C/C++
| code in browser engines. And trying to get people who actually do
| this for a living there? It's a rather tough endeavor [4]
|
| So, I wouldn't hold my breath for a decision on conditionals. Or
| for conditionals in general.
|
| [1] https://design-system.w3.org
|
| [2] https://www.w3.org/TR/ambient-light/
|
| [3] https://design-system.w3.org/third-party-plugins/
|
| [5] See "Solutions
| https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
| tediousdemise wrote:
| Semantically, "when" implies that something will happen, whereas
| "if" implies that it could happen.
| munk-a wrote:
| When pigs fly I'll accept that "when" implies that something
| will happen.
| goatlover wrote:
| Why would you write a when statement for something that can't
| happen?
| munk-a wrote:
| If you're talking about in english "when pigs fly is" a
| common idiom.
|
| If you're talking about code - sometimes it's nice to have
| extra-defensive code even if it's mostly inconceivable it
| will ever be triggered (especially if this will be used as
| a library for a lot of folks) but mostly you wouldn't.
| [deleted]
| aidenn0 wrote:
| When you write conditionals for events that will never happen
| in your CSS you are doing it wrong.
| [deleted]
| 6510 wrote:
| Short is good but it shouldn't be to short. I would like to be
| able to search the web when I run into some syntax.
|
| It doesn't seem like it is considered often.
|
| For example: searching for "js ..." doesn't product results for
| spread operator or destructuring assignment. You would have to
| ask someone what is going on and the answer would have to not
| confuse the 2 eventho they share syntax.
|
| "CSS if/else" obviously does produce many search results and for
| "CSS when" I get only 3. It seems everyone already knows what
| they are talking about. This is how we build human languages.
|
| Personally I would prefer it if CSS was frozen and a new style
| type was introduced to contain all the heretical Turing-
| equivalency A style sheet should probably never have without
| disappointing those who really really want it.
|
| Then we could say: You shall not load this x-domain.
| steerablesafe wrote:
| As an outsider to web development, @when would be a weird choice.
| If CSS wants to enable 3rd party tooling to take some of the
| syntax space, then it should declare some parts of the syntax
| never to be taken by core CSS (if it's not already done this
| way). Then this syntax clash would never be a problem between a
| 3rd party tool like sass and CSS.
|
| In this case I think it's on sass to introduce the awkward
| workaround on the syntax clash.
| pie_flavor wrote:
| I think `when` would be a good name for this even if Sass didn't
| exist - CSS is not a procedural language, it is a _flow_
| language. That is, the conditional block is applied reactively to
| the condition changing, not just the first time the file is
| evaluated. Sass 's usage of `if` is the latter, which is how a
| programmer intuitively thinks about `if`, and since the CSS
| construct is the former, it makes sense to use a different word
| to highlight that there _is_ a difference.
| thih9 wrote:
| There are many non-procedural languages or environments that
| still have 'if'. E.g. SQL's IF-THEN-ELSE, XSL's 'xsl:if', or C
| preprocessor's '#if'. Is there a language similar to CSS that
| uses something different than 'if' to solve a similar problem?
| kazinator wrote:
| It's so confusing how the % character is used in Lex and Yacc.
| ISO C should introduce a _modulo_ keyword to graciously get out
| of the way of these tools.
| darrinmn wrote:
| It saddens me whenever a core web spec picks a sub-optimal
| solution purely because a 3rd party tool already picked the
| optimal one.
|
| I find it ironic that the css "when/else" draft spec uses "if"
| for describing the conditional scenarios in plain english. As if
| the spec itself admits the syntax they are choosing is clearly
| sub-optimal.
| veidelis wrote:
| It was the same with Array includes and contains, wasn't it?
| kretaceous wrote:
| Also, Array.flat was chosen instead of Array.flatten because
| of a popular 3rd party library's function of the same name. I
| think it was Lodash.
| abdusco wrote:
| It was mootools.
|
| https://developers.google.com/web/updates/2018/03/smooshgat
| e
| mananaysiempre wrote:
| ... And underscore/lodash use the _(...) wrapper approach
| pioneered by jQuery's $(...) precisely to avoid monkey-
| patching builtin objects like Mootools did (as well as
| some others I think, but I don't really remember).
| Izkata wrote:
| PrototypeJS also had the monkey-patch approach.
| adastra22 wrote:
| Would if/else have been considered optimal to you if you hadn't
| already been conditioned (ha!) that way by other programming
| languages?
|
| "When" actually seems better in a purely declarative language.
| freediver wrote:
| Came to post that there is something incredibly soothing in the
| small illustrations that the author uses to end their blog posts.
| draw_down wrote:
___________________________________________________________________
(page generated 2022-03-14 23:00 UTC)