Is there a precedence to combinators like
a > b ~ c d
(Note the space between c and d is the descendant combinator)
Or is it just read left-to-right, like
((a > b) ~ c) d
?
No, there is no notion of precedence in combinators. However, there is a notion of order of elements in a complex selector.
Any complex selector can be read in any direction that makes sense to you, but this does not imply that combinators are distributive or commutative, as they indicate a relationship between two elements, e.g. ancestor descendant and previous + next. This is why the order of elements is what matters.
According to Google, however, browsers implement their selector engines such that they evaluate complex selectors from right to left:
The engine [Gecko] evaluates each rule from right to left, starting from the rightmost selector (called the "key") and moving through each selector until it finds a match or discards the rule.
Mozilla's article, Writing Efficient CSS for use in the Mozilla UI has a section that describes how their CSS engine evaluates selectors. This is XUL-specific, but the same layout engine is used both for Firefox's UI and pages that display in Firefox's viewport. (dead link)
As described by Google in the above quote, the key selector simply refers to the right-most simple selector sequence, so again it's from right to left:
The style system matches rules by starting with the key selector, then moving to the left (looking for any ancestors in the rule’s selector). As long as the selector’s subtree continues to check out, the style system continues moving to the left until it either matches the rule, or abandons because of a mismatch.
Bear in mind two things:
These are documented based on implementation details; at heart, a selector is a selector, and all it is intended to do is to match an element that satisfies a certain condition (laid out by the components of the selector). In which direction it is read is up to the implementation; as pointed out by another answer, the spec does not say anything about what order to evaluate a selector in or about combinator precedence.
Neither article implies that each simple selector is evaluated from left to right within its simple selector sequence (see this answer for why I believe this isn't the case). What the articles are saying is that a browser engine will evaluate the key selector sequence to figure out if its working DOM element matches it, then if it does, progress onto the next selector sequence by following the combinator and check for any elements that match that sequence, then rinse and repeat until either completion or failure.
With all that said, if you were to ask me to read selectors and describe what they select in plain English, I would read them from right to left too (not that I'm certain whether this is relevant to implementation details though!).
So, the selector:
a > b ~ c d
would mean:
Select any d element
that is a descendant of a c element
that is a sibling of, and comes after, a b element
that is a child (direct descendant) of an a element.
It doesn't matter.
a > b c
will match the same elements regardless of whether you do it
(a > b) c
or
a > (b c)
I think that browsers go right-to-left.
the spec doesn't mention anything about precedence (that I can find) but I believe it's strictly left -to- right evaluation
Related
I'm not sure which is the official website, I've found getbem.com and en.bem.info.
One suggests using -- for the modifier (Naming):
CSS class is formed as block’s or element’s name plus two dashes.
The other _ for the modifier (Modifier name):
A modifier name is delimited by a single underscore (_).
I know I can use either, and really it's just important to be consistent, but I like to try and use official specs whenever possible.
Which is the official website..?
Should I really be using -- or _ for modifiers..?
Which is the official website?
BEM started as an informal set of guidelines by Yandex, which they later formalized on en.bem.info, so in that regard en.bem.info is the "canonical" version of BEM.
With that said, there are many flavors of BEM, and I myself use a variant influenced largely by Harry Roberts and Nicolas Gallagher.
This brings me to your next question:
Should I really be using -- or _ for modifiers?
To that my answer is: you should be consistent in your usage, but you may use whatever character(s) you'd like for the variant of BEM that you're using. Just be sure that everyone on your team understands which variant you're standardizing on.
This is similar to using tabs vs two spaces vs four spaces (vs hotdogs). It doesn't actually make a difference beyond being something that people tend to have an irrationally strong personal preference for.
To help normalize people, I use an example syntax of a block, element, and modifier that shows what the variant is normalizing on:
I used to primarily use:
the-block__the-element--the-modifier
But I now prefer:
TheBlock_theElement-theModifier
for its brevity.
I would like to understand how keyword proof works in an Isar proof. I consulted the Isabelle/Isar reference, section 6.3.2 and Programming and Proving in Isabelle/HOL, section 4.1.
To summarise what I have learned, there are three ways of beginning a proof by the keyword proof:
without any argument Isabelle finds a suitable introduction rule to the lemma being proved and applies it in a forward mode
if a hyphen: - is supplied as an argument, then proof does nothing to the goal, avoiding any automatic rule being applied when it would lead to a blind alley
if a specific rule, like rule name, unfold true_def, clarify or induct n is supplied, then it is applied to the goal in a forward mode
Am I right that the third case is like using apply with the argument supplied?
How is the automatic introduction rule in the first case picked by the system?
And, does the above fully describe the usage of proof?
The command proof without a method specification applies the method default. The method default is almost like rule, but if rule fails, then it tries next intro_classes and then unfold_locales. The method rule without being given a list of theorems tries all rules that are declared to the classical reasoner (intro, elim, and dest). If no facts are chained in, only intro rules are considered. Otherwise, all types of rules are tried. All chained-in facts must unify with the rules. dest rules are transformed into elim rules before they are applied.
You can print all declared rules with print_rules. Safe rules (intro!, elim!, ...) are preferred over normal rules (intro, elim, ...) and extra rules (intro?, elim?) come last.
You can also use rule without giving any rules. Then, it behaves like default, but without the fallbacks intro_classes and unfold_locales.
Andreas gave a good description of how proof without a method argument works; I'll just cover some other parts of the question.
First, proof (method) is like apply (method) except for one thing: While apply leaves you in "prove" mode, where you can continue with more apply statements, proof transitions into "state" mode, where you must use a have or show statement to continue proving. Otherwise the effect on the goal state is the same.
I'd also like to point out that case 2 (proof -) is really an instance of case 3, because - is actually an ordinary proof method just like rule name or induct (you can also write apply -, for example). The hyphen - proof method does nothing, except that it will insert chained facts into the current goal, if it is given any chained facts.
The CSS Working Group's "Cascading Style Sheets (CSS) Snapshot 2010" says:
Each level of CSS builds on the previous, refining definitions and
adding features. The feature set of each higher level is a superset of
any lower level, and the behavior allowed for a given feature in a
higher level is a subset of that allowed in the lower levels. A user
agent conforming to a higher level of CSS is thus also conformant to
all lower levels.
I do not understand the sentence that I've emphasized in bold. Shouldn't it say that the behavior for a feature in a higher level is a superset of that allowed in in a lower level?
Can anyone provide an example to clarify it?
The CSS Snapshot 2010 is as a whole vague and partly outdated. In the statement quoted, both “feature” and “behavior” are loose words, not well-defined terms, so the statement does not have an exact meaning. It seems probable that the meant “superset”, not “subset”. In any case, what the text says is partly incorrect: there are changes and omissions between “levels”. The “level” concept isn’t exact, far from that; there is no authoritative list of specifications and drafts that belong to “level 3”
I have always thought the definition of both of these were functions that take other functions as arguments. I understand the domain of each is different, but what are their defining characteristics?
Well, let me try to kind of derive their defining characteristics from their different domains ;)
First of all, in their usual context combinators are higher order functions. But as it turns out, context is an important thing to keep in mind when talking about differences of these two terms:
Higher Order Functions
When we think of higher order functions, the first thing usually mentioned is "oh, they (also) take at least one function as an argument" (thinking of fold, etc)... as if they were something special because of that. Which - depending on context - they are.
Typical context: functional programming, haskell, any other (usually typed) language where functions are first class citizens (like when LINQ made C# even more awesome)
Focus: let the caller specify/customize some functionality of this function
Combinators
Combinators are somewhat special functions, primitive ones do not even mind what they are given as arguments (argument type often does not matter at all, so passing functions as arguments is not a problem at all). So can the identity-combinator also be called "higher order function"??? Formally: No, it does not need a function as argument! But hold on... in which context would you ever encounter/use combinators (like I, K, etc) instead of just implementing desired functionality "directly"? Answer: Well, in purely functional context!
This is not a law or something, but I can really not think of a situation where you would see actual combinators in a context where you suddenly pass pointers, hash-tables, etc. to a combinator... again, you can do that, but in such scenarios there should really be a better way than using combinators.
So based on this "weak" law of common sense - that you will work with combinators only in a purely functional context - they inherently are higher order functions. What else would you have available to pass as arguments? ;)
Combining combinators (by application only, of course - if you take it seriously) always gives new combinators that therefore also are higher order functions, again. Primitive combinators usually just represent some basic behaviour or operation (thinking of S, K, I, Y combinators) that you want to apply to something without using abstractions. But of course the definition of combinators does not limit them to that purpose!
Typical context: (untyped) lambda calculus, combinatory logic (surprise)
Focus: (structurally) combine existing combinators/"building blocks" to something new (e.g. using the Y-combinator to "add recursion" to something that is not recursive, yet)
Summary
Yes, as you can see, it might be more of a contextual/philosophical thing or about what you want to express: I would never call the K-combinator (definition: K = \a -> \b -> a) "higher order function" - although it is very likely that you will never see K being called with something else than functions, therefore "making" it a higher order function.
I hope this sort of answered your question - formally they certainly are not the same, but their defining characteristics are pretty similar - personally I think of combinators as functions used as higher order functions in their typical context (which usually is somewhere between special an weird).
EDIT: I have adjusted my answer a little bit since - as it turned out - it was slightly "biased" by personal experience/imression. :) To get an even better idea about correctly distinguishing combinators from HOFs, read the comments below!
EDIT2: Taking a look at HaskellWiki also gives a technical definition for combinators that is pretty far away from HOFs!
I'm a (theoretical) computer science student, and as such the investigating of semantics of programming languages is one of the subjects of my study (wikipedia).
I've played around a lot with CSS and have a reasonable understanding of the box positioning rules. (If you tell me to create a page with certain layout, I can often think of the correct box approach and applicable CSS rules.)
It would be cool to have some sort of formal semantics for the CSS box positioning rules, but after searching the net for a while, I couldn't quite find anything useful.
I mostly simply end up at the CSS specifications, which are formatted as long texts with pseudo-algorithms (not the greatest reading matter --- I haven't read any of these specifications with much effort just yet).
Has no one tried to formalize this “theory” into some mathematical model, more rigorous than what the specifications have to offer? I'm not looking for something complete or definitive, but it sure would be neat (and useful!) if, at least, the way boxes should be positioned could be modeled in a formal manner.
Does anyone know of such research?
Not an answer! This is an example of a possible formalization of a very simplified case (see my comment above).
Say, for instance, we're working in a world featuring (1) a known screen width , (2) an ordered list of boxes which aren't nested, have no margins/padding's/borders, are floated left and of which we know their (2.1) height and (2.2) width via the mathematical functions and .
We'll be defining the functions and , which state the coordinates of the left upper corner of each box.
We'll be defining/using the relations " starts line " and " has height ".
First of all, starts line 0.
Then, if starts line , and furthermore if for certain
...we conclude that:
has height
starts line +1 iff
These rules define the positions of given boxes in a formal manner. It's only one way to do so, of course, and probably not the smartest (just thought it up quickly), but it does correctly formalize the way floats work (modulo typos, I haven't checked it over well enough).
When dealing with programming languages, one can choose of many of these formalisms, each invented for particular purposes (see wikipedia).
I'm just interested if anyone has ever tried to come up with some formalization for CSS box positioning. Of course the specifications go a long way, but they're just not quite as rigorous as the mathematical way forces you to be.