According the CSS Level 3 specification, for parsing the start of an identifier, you:
Check if three code points would start an identifier
Look at the first code point:
If the first character is -, then we have a valid identifier if:
The second code point is an identifier-start code point ([a-zA-Z_] or non-ASCII).
The second code point is -.
The second and third character form a valid escape.
Otherwise, we do not have a valid identifier start. After determining if we have a valid identifier start, the only requirements to have a valid <ident-token> is we have 0 or more of any combination of the following:
Escape tokens
ASCII letters
Digits
_ or -
Non-ASCII characters
Since we do not require any characters following an identifier start token, this would suggest that -- is a valid identifier, even if never supported by any browser or framework. However, even official CSS validation services (maintained by those that design the CSS specifications) do not consider this a valid identifier. Is this merely a bug in the validation service?
Yes it's valid and it works. It's the shortest custom property (aka CSS variable) that you can define:
body {
--:red;
background:var(--);
}
Related: Can a css variable name start with a number?
The -- custom property identifier is reserved for future use, but current browsers incorrectly treat it as a valid custom property.
See also
w3c/csswg-drafts#6313
Related
I'm curious, and I was not able to find an explanation so far.
In RFC 5280 Extensions define the following:
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
-- contains the DER encoding of an ASN.1 value
-- corresponding to the extension type identified
-- by extnID
}
What is the reason for defining the encapsulating OCTET_STRING for extnValue, instead of directly defining extnValue as the "DER encoding of an ASN.1 value corresponding to the extension type identified by extnID".
Thank you.
Not an authoritative answer, but my thoughts are: this is because extension values may have arbitrary enclosing tags and can be defined in external modules:
Most extensions use SEQUENCE, but some are not, like in a given example, Subject Key Identifier is just another OCTET_STRING, Key Usages is a BIT_STRING. And in base type definition you have to use fixed tag to represent variable content (ANY).
In addition, parsers may not know how to parse particular extension, so they read it as octet string without having to dig deeper if extension type is unknown to parser.
update 13.02.2023 (based on comments):
Regarding the type / tag, from my understanding, each different type can be easily identified by the leading tag byte, such as SEQUENCE=0x10, OCTET_STRING=0x04 or BIT_STRING=0x03
you cannot define the field with variable tag, because you introduce type ambiguity. That is, extnValue ANY field definition is not valid, because its type is indeterminate. When you define a type (in this case, it is Extension type), all fields must have deterministic tag.
I am storing XBRL JSON using elasticsearch.
This xBRL-JSON OIM spec describes the oim:period property:
Otherwise, an ISO 8601 time interval representing the {interval}
property, expressed in one of the following forms:
<start>/<end>
<start>/<duration>
<duration>/<end>
Where <start> and <end> are valid according to the xsd:dateTime datatype, and <duration> is valid according to xsd:duration.
Examples from arelle's plugin look like this:
2016-01-01T00:00:00/PT0S
2015-01-01T00:00:00/P1Y
I notice that arelle's plugin exclusively produces this format:
<start>/<duration>
My question
Is there a way to save at least the <start> part as a date type in elasticsearch?
Ideas I had:
elastichsearch only (my preference)
Use a custom date format which anticipates the /<duration> part, but ignores it
I haven't checked Joda yet; will it ignore characters in the date format if they aren't part of the special character? Like the "/" delimiter or the "P" which precedes any duration value (like PT0S and P1Y above)?
EDIT So the single-quote character escapes literals; this works yyyy'/P' will accept a value '2015/P'. However, the rest of the duration could be more dynamic
Re: dynamic; will Joda accept regex or wildcard character like "\d" or "+" qualifier so I can ignore all the possible variations following the P?
Use a character filter to strip out the /<duration> part before saving only <start>as datetime. But I don't know if character filters happen before saving as type: date. If they don't, the '/`part isn't stripped, and I wouldn't be passing valid date strings.
Don't use date type: Use a pattern tokenizer to split on /, and at least the two parts will be saved as separate tokens. Can't use date math, though.
Use a transformation; although it seems like this is deprecated. I read about using copy_to instead, but that seems to combine terms, and I want to break this term apart
Some sort of plugin? Maybe a plugin which will fully support this "interval" datatype described by the OIM spec... maybe a plugin which will store its separate parts...?
change my application (I prefer to use elasticsearch-only techniques if possible)
I could edit this plugin or produce my own plugin which uses exclusively <start> and <end> parts, and saves both into separate fields;
But this breaks the OIM spec, which says they should be combined in a single field
Moreover it can be awkward to express an "instant" fact (with no duration; the PT0S examples above); I guess I just use the same value for end property as start property... Not more awkward than a 0-length duration (PT0S) I guess.
Not a direct answer, but it's worth noting that the latest internal drafts of the xBRL-JSON specification have moved away from the the single-field representation. Although the "/" separated notation is an ISO standard, tool support for it appears to be extremely poor, and so the working group has chosen to switch to separate fields for start and end dates. I would expect Arelle support to follow suit in due course.
CSS3 added the <column-token> operator as follow:
<column-token>: ||
It also says:
<column-token> has been added, to keep Selectors parsing in single-token lookahead.
So, is that just an artifact of the lexer, or is that an actual operator used for something I do not know about yet?
CSS level 4 does in fact have a column operator (used to select table cells of a column).
No idea if that's related and the token was added to CSS3 to be forward-compatile - it would be strange, but then the naming does not sound coincidental. The argument for the new token was indeed parsing convenience:
I just added a COLUMN token to the Syntax draft, matching "||". It's
needed for Selectors, so it can maintain LL(1). (Otherwise, seeing
"*" followed by "|" is ambiguous until you look at the next token.)
Which I admit I don't quite understand. What else could *| be interpreted as, even in CSS4? There is no other valid use of | in a selector (except inside an attribute matcher, but there there is no valid use for ||). CSS4 Values uses both *, | and || but that's not the spec the email was referring to.
This is not strictly a CSS3 feature, column-token is just one of many tokens used to parse currently interpreted CSS stylesheet by CSS parser. So it has no use for you unless you're implementing a CSS parser.
I'm pentesting the ASP.NET application running on Microsoft-IIS/7.5 web server and I'm sending it the following GET request parameters:
&search=aaa%20%*+,-/;<=>^|"'bbb
One of the parameters is search, where I've inputed the value that can be seen above. The value is printed in the returned response two times as follows:
The first parameter:
<input name="nn" type="text" value="aaa %* ,-/;<=>^|"'bbb" class="cc" />
Quoted parameters in the first entry are as follows:
" ==> "
' ==> '
< ==> <
I guess there's no way to break out of there, since the value is escaped and we can't input the " character right. Nevertheless, all parameters are not properly escaped, even though it's not possible to break out.
The second parameter:
<strong>aaa %* ,-/;<=>^|"'bbb</strong>
We can see that all of the characters are presented as they are, but there's a catch. After the < character there can't be any [a-zA-Z0-9] (maybe some other as well) characters, because we're probably getting blocked by the ASP.NET filters.
If we input the following:
&searchQuery=aaa<#script>alert('Hi');<#/script>bbb
We get the following output:
<strong>aaa<#script>alert('Hi');<#/script>bbb</strong>
I'm asking if you see any way to break out of the restrictions and execute arbitrary JavaScript code nevertheless?
THank you
HTML requires the tag name to immediately follow the start tag open delimiter <:
Start tags must have the following format:
The first character of a start tag must be a U+003C LESS-THAN SIGN character (<).
The next few characters of a start tag must be the element's tag name.
[…]
Anything beyond that is up to a browser’s interpretation quirks.
But there are also other tags than element tags like markup declaration tags (<!…>), processing instruction tags (<?…>) and alternative comment tags (<%…%>) that are recognized by certain browsers and allow certain hacks.
Have a look at the common XSS cheat sheets like OWASP’s XSS Filter Evasion Cheat Sheet and the HTML5 Security Cheatsheet, or some HTML fuzzers like Shazzer.
There seems to be a breaking (i.e. backwards-incompatible) change in the CSS Syntax Module Level 3 specification upcoming draft: trailing semicolon after the last declaration in a block is now perhaps required.
Compare the old wording (W3C Working Draft 13 August 2003):
4.8. Rule sets, declaration blocks, and selectors
A declaration-block (also called a {}-block in the following text) starts with a left curly brace ({) and ends with the matching right curly brace (}). In between there must be a list of zero or more semicolon-separated (;) declarations.
with the new one (Editor's Draft 14 June 2012):
2. Description of CSS's Syntax
A rule starts with a selector (defined by the Selectors specification), then has a {}-wrapped block containing a sequence of declarations. The selector specifies which elements the declarations will apply to. Each declaration has a property name, followed by a colon and the property value, and finished with a semicolon.
(emphasis mine).
So that nifty short forms, e.g.:
em { color: lime }
(this is currently given as valid example in the CSS Color Module Level 3 recommendation) will no longer validate.
Could someone more knowledgeable about the whole Level 3 drafts collection please verify? To future-proof stylesheets, do we really have to overhaul existing CSS files (and insert semicolons if missing) before the specification gets finalized or did I misunderstand something?
Looks like there currently is an ambiguity in the spec.
You correctly pointed out that 2. Syntax Description section prescribes ending every rule with a semicolon:
Each declaration has a property name, followed by a colon and the property value, and finished with a semicolon.
And at the same time, description of the parsing automaton in section 3.6.8. Declaration-value mode reads that a closing brace without a semicolon correctly ends a declaration and current rule at the same time:
} token
Append the current declaration to the value of the current rule. Pop the current rule from the stack of open rules, and append it to the value of the new current rule. Switch to the current rule's content mode.
So according to 3.6.8 trailing semicolon is optional.
I can't say about actual intention of the specification authors. But current situation should probably be reported and fixed. Most certainly they don't have intention of breaking the compatibility with CSS 2.1 and will reword their Syntax Description section in the final version.
I think that it's just a mistake when writing the specifications, and that the real intention was to have it as a separator, just as in previous versions. I expect this to be adjusted in later drafts.
The W3C validation service says that the example without the trailing semicolon is valid CSS level 3.
I will however, as I have always done, end each declaration with a semicolon. This is a good practice, so that you don't forget the separator when you add more declarations.
This is an example of the 'separator-terminator' problem. Evidently CSS 3 has moved from the semicolon being a separator to the semicolon being a terminator. That means it is required after every element, not just between the elements. Pascal (separator) and C (terminator) provide other examples. This leads to apparent anomalies in Pascal such as semicolon being illegal before 'else' or 'until'. Why CSS 3 adopted a CSS-2-incompatible rule is beyond me, and whether implementations will insist on it is another matter, but the intent of the quotation is clear: it's a terminator and must therefore be present on all entries including the last.