3.4. Resource Locators: the <url> type describes a <url-modifier> at
A URL is a pointer to a resource and is a functional notation
denoted by <url>. The syntax of a <url> is:
<url> = url( <string> <url-modifier>* )
In addition to the syntax defined above, a can sometimes be
written in other ways:
For legacy reasons, a <url> can be written without quotation marks around the URL itself. This syntax is specially-parsed, and
produces a <url-token> rather than a function syntactically.
[CSS3SYN]
Some CSS contexts, such as #import, allow a <url> to be represented by a <string> instead. This behaves identically to
writing a url() function containing that string. Because these
alternate ways of writing a <url> are not functional notations, they
cannot accept any <url-modifier>s.
Note: The special parsing rules for the legacy quotation mark-less
<url> syntax means that parentheses, whitespace characters, single
quotes (') and double quotes (") appearing in a URL must be escaped
with a backslash, e.g. url(open\(parens), url(close\)parens).
Depending on the type of URL, it might also be possible to write these
characters as URL-escapes (e.g. url(open%28parens) or
url(close%29parens)) as described in[URL]. (If written as a
normal function containing a string, ordinary string escaping rules
apply; only newlines and the character used to quote the string need
to be escaped.)
at
3.4.2. URL Modifiers
The url() function supports specifying additional <url-modifier>s,
which change the meaning or the interpretation of the URL somehow. A
<url-modifier> is either an <ident> or a function.
This specification does not define any <url-modifier>s, but other
specs may do so.
See also CSS Values and Units Module Level 3
Editor’s Draft, 21 March 2016
What are example usages of <ident> and function at url() ?
What are differences between <string> , <ident>, function at url() ?
A <url-modifier> is either an <ident> or a function.
<ident> is an identifier.
A portion of the CSS source that has the same syntax as an <ident-token>.
<ident-token> Syntax ;
I could not find any examples of <ident> used within the url function but
as mentioned in this email there are some possible future uses.
Fetch options to control CORS/cookies/etc
working with Subresource Integrity
Looking at the <ident> syntax you cannot use a key/value pair so i assume
most of this would be implemented using a function which does not yet exist., resource hinting could be implemented using <ident>.
.foo {
background-image: url("//aa.com/img.svg" prefetch);
}
I did however find a "A Collection of Interesting Ideas" with a function <url-modifier> defined.
SVG Parameters (not official spec)
The params() function is a <url-modifier>
.foo {
background-image: url("//aa.com/img.svg" param(--color var(--primary-color)));
}
Related
I want to use values from gradle.properties that should go into a template string.
A naive first:
println("${project.properties[somekey]}")
doesn't work: Unresolved reference: somekey
So, quotes required?
println("${project.properties[\"somekey\"]}")
is completely broken syntax: Expecting an expression for the first .
I couldn't find any example how to do this, yet the official documentation says expressions.
Question: is it possible to access a map in string template, and if so, how?
Yes and as follows:
"${project.properties["someKey"]}"
assuming the Map has the following signature: Map<String, Any?> (or Map<Any...)
Alternatives:
"${project.properties.getValue("someKey")}"
"${project.properties.getOrElse("someKey") { "lazy-evaluation-default-value" }}"
"${project.properties.getOrDefault("someKey", "someFixedDefaultValue")}"
Basically all the code you put in the ${} is just plain Kotlin code... no further quoting/escaping required, except for the dollar sign $ itself, e.g. use "\$test" if you do not want it to be substituted with a variable named test or """${"$"}test""" if you use a raw string
Note that in this println case the following would have sufficed as well (which also goes for all the shown alternatives above. You may omit the outer surrounding quotes and ${} altogether):
println(project.properties["someKey"])
See also Basic types - String templates
When trying to use the oXygen editor to comment out a node inside of an element oXygen simply wrapped it into (:<foo>foo 1</foo>:), but I then found out that that way the node did not get commented out but was rather prefixed by a text node with (: and suffixed by a text node with :).
Then I looked up the syntax and found out you need to use an enclosed expression {(:<foo>foo 1</foo>:)} instead to have access to the comment syntax.
However, while BaseX and Saxon 9.8 happily accept {(:<foo>foo 1</foo>:)}, Altova complains and needs an additional empty sequence {(:<foo>foo 1</foo>:)()}.
https://www.w3.org/TR/xquery-31/#doc-xquery31-EnclosedExpr suggests in XQuery 3.1 the expression inside curly braces is optional and defaults to ().
Does this also mean that in XQuery 3.1 it should suffice to use simply the comment inside of the curly braces, without an empty sequence?
So to summarize, Saxon and BaseX allow me to use <root>{(:<foo>foo 1</foo>:)}</root> while Altova complains about incorrect syntax, forcing me to use <root>{(:<foo>foo 1</foo>:)()}</root>.
Is that still necessary in XQuery 3.1?
Sounds like a bug in their commenter, which is pretty common in XQuery editors. Within in an element - and assuming you are using direct element constructors, not computed element constructors - use XML comments:
<hello>world
<!-- Don't print me -->
</hello>
Computed element constructors still use XQuery comments:
element hello {
'world' (: Don't print me :)
}
Given the following examples which I picked up from here:
CSS.escape(".foo#bar") // "\.foo\#bar"
CSS.escape("()[]{}") // "\(\)\[\]\{\}"
Since .foo#bar is a valid CSS selector expression. Why we need to append \ before some characters? Suppose I want to write my own program which does the same task of escaping all the values/expressions in a CSS file then, how should I proceed?
PS: I am always confused about the escaping, how should I think when it comes to escaping some input?
You escape strings only when those strings contain special symbols that you want to be treated literally. If you are expecting a valid CSS selector as user input, you shouldn't be escaping anything.
.foo#bar is a valid CSS selector, but it means something completely different from \.foo\#bar. The former matches an element with that respective class and ID, e.g. <div class=foo id=bar> in HTML. The latter matches an element with the element name ".foo#bar", which in a hypothetical markup language could be represented as <.foo#bar> (obviously this is not legal HTML or XML syntax, but you get the picture).
I have a div which will receive a CSS background image from user chosen URL, like so:
background-image: url("/* user specified URL here*/")
How should I escape the URL so that it's safe to embed in the CSS? Is escaping the quotes enough?
If you are setting the background url through JS, then the correct and safe ways is using encodeURI() and wrapping in quotes.
node.style.backgroundImage = 'url("' + encodeURI(url) + '")';
Is escaping the quotes enough?
No, you also should worry about backslashes and newlines.
Here is the CSS grammar for a double quoted URI:
http://www.w3.org/TR/CSS21/grammar.html#scanner
"([^\n\r\f\\"]|\\{nl}|{escape})"
where {nl} is
\n|\r\n|\r|\f
and {escape} is a backslash-escaped character. So a trailing backslash will break your CSS. A non-escaped newline likewise.
I would strongly recommend to remove all whitespace and finally escape " and \
Since the user data that you need to insert into CSS can be treated like a URL, and not just a string, you only need to ensure that it is properly URL-encoded.
This is safe because a well-formed URL does not contain any characters that are unsafe in CSS strings; except for apostrophe ('), which is not a problem as long as you use double quotes for your CSS string: url("...")
A simple way to do this is to URL-encode all characters that are not "reserved" or "unreserved" in URLs. According to RFC 3986, that would be all characters except for these:
A-Z a-z 0-9 ; , / ? : # & = + $ - _ . ! ~ * ' ( ) # [ ]
That is what encodeURI() does in Mārtiņš Briedis's JavaScript answer. (With one exception: encodeURI() encodes [ and ], which is mostly inconsequential.)
In addition to that, you might consider only allowing URLs that begin with https: or data:. By doing this you can prevent mixed content warnings if the page is served over HTTPS, and also avoid the javascript: issue Alexander O'Mara commented on.
There might be other URL parsing and validation that you want to do, but that is outside the scope of this question.
If you need to insert user data into a CSS string that cannot be treated like a URL, then you would need to do CSS backslash escaping. See user123444555621's answer for more on that.
const style = "background-image: url(\"" + CSS.escape(imageUrl) + "\")";
See https://developer.mozilla.org/en-US/docs/Web/API/CSS/escape
It is an experimental new thing, but it seems to be quite well supported (as of 2021).
I am trying to learn to use JavaCC and realized that it has support for regular expressions. Call me lazy but I thought the default/common way to define digits is a bit too long:
TOKEN : { < #DIGITS : (["0" - "9"])+ >}
I tried using the shorthand character classes such as:
TOKEN : { < #DIGITS : (\d)+ >}
but the "compiler compiler" doesn't seem to like it. I get Lexical errors for the shorthand character. I could not find any documentation on the matter so I am not sure if I am doing something wrong or that it's simply not supported. If anyone can confirm/deny my assumption, that javacc not playing well with the shorthand character classes, I would be very appreciative.
Your finding that it's not supported is correct. Regular expressions in JavaCC are made up only of string literals, references to other regular expressions, and references to the predefined regular expression < EOF >.
However, what you are doing with the code you have there is creating your own shortcut. The number sign means that the symbol is private, i.e., can be used only inside regular expressions. So, defining it as TOKEN : { < #D : (["0" - "9"])+ > } means you could then use < D > within other token definitions.
The example grammar javacc.jj, included with the binary distribution, is the official grammar, so looking in this file you can see just what is parsable by this grammar. The output seems to be a essentially a grammar validator.