| Age | Commit message (Collapse) | Author |
|---|
|
This allows us to see which custom properties apply to a given element,
which previously wasn't shown.
|
|
|
|
|
|
Now that LibUnicode generates these patterns, the AO steps to retrieve
them may be implemented.
|
|
In a future commit, the "part" view returned from FormatDateTimePattern
may be a view into a string that goes out of scope. Ensure the AO only
returns valid views. A similar approach is used in Intl.NumberFormat.
|
|
The fields of the generated elements must be in the same order as the
table here:
https://unicode.org/reports/tr35/tr35-dates.html#Date_Field_Symbol_Table
Further, only one field from each group of fields is allowed.
|
|
|
|
Pattern skeletons are more or less the "key" of format patterns. Every
format pattern is assigned a skeleton. Interval patterns (which are not
yet parsed) are also assigned a skeleton - this is used to match them to
an "owning" format pattern. So we will use the skeleton generated here
to match format patterns at runtime with their available interval
patterns.
An alternative approach would be to append interval patterns directly to
their owning format pattern, but this has some draw backs:
1. Skeletons aren't totally unique. A skeleton may appear in both
the "dateFormats" and "availableFormats" objects, in which case
the same interval formats would be generated more than once.
2. Otherwise unique format patterns may only differ by the interval
patterns assigned to them. This would cause the UniqueStorage for
the format patterns to increase in size, impacting both compile
times and libunicode.so size.
|
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/665871e
|
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/513c05b
|
|
Persist EditingEngine mode in HackStudio and TextEditor when opening new
files or editing splits. Previously, the EditingEngine defaulted to a
RegularEditingEngine for a new Editor, even if Vim Emulation had been
selected in the existing Editor.
|
|
This will allow users of EditingEngine classes to determine current type
of EditingEngine (currently either vim or regular).
|
|
|
|
We now detect situations like this, where variables infinitely recur,
without crashing:
```css
div {
--a: var(--b);
--b: var(--a);
background: var(--a);
}
p {
--foo: var(--foo);
background: var(--foo);
}
```
|
|
We now stop processing variables once a length of 16384 tokens is
reached. This is an arbitrary number, but should be far beyond what
anyone will reasonably use, and small enough to not crash.
|
|
|
|
If a property is custom or contains a `var()` reference, it cannot be
parsed into a proper StyleValue immediately, so we store it as an
UnresolvedStyleValue until the property is compute. Then, at compute
time, we resolve them by expanding out any `var()` references, and
parsing the result.
The implementation here is very naive, and involves copying the
UnresolvedStyleValue's tree of StyleComponentValueRules while copying
the contents of any `var()`s it finds along the way. This is quite an
expensive operation to do every time that the style is computed.
|
|
This represents a property value that hasn't been converted to a
"proper" StyleValue yet. That is, it's either a custom property's value,
or a value that includes `var()` references, (or both!) since neither of
those can be fully resolved at parse time.
|
|
For our naive var() implementation, we need to be able to create
StyleBlockRules outside of the Parser, and these changes make that
possible.
|
|
|
|
|
|
This allows JS to keep an element alive by retaining a reference to
element.attributes
|
|
This allows document.implementation to keep the underlying document
alive for as long as we need it (for example, if someone holds on to a
DOMImplementation JS wrapper after the document is GC'd.)
|
|
This object already forwarded its ref count to DOM::Window. This patch
simply adopts the new RefCountForwarder base to achieve the same thing.
|
|
|
|
Found while working on something else.
|
|
|
|
Only two skipped tests remaining overall :^)
|
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/271d71c
|
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/7207a1c
|
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/1f7e486
|
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/516bf24
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There are a few FIXMEs that will need to be addressed, but this
implements most of the prototype method. The FIXMEs are mostly related
to range formatting, which has been entirely ignored so far. But other
than that, the following will need to be addressed:
* Determining flexible day periods must be made locale-aware.
* DST will need to be determined and acted upon.
* Time zones other than UTC and calendars other than Gregorian are
ignored.
* Some of our results differ from other engines as they have some
format patterns we do not. For example, they seem to have a lonely
{dayPeriod} pattern, whereas our closest pattern is
"{hour} {dayPeriod}".
|
|
Unlike the locale, the data locale has Unicode locale extensions removed
(e.g. the data locale for "en-US-u-ca-gregory" is just "en-US"). Cache
the data locale for LibUnicode lookups during formatting.
|
|
|
|
|
|
|
|
|
|
The parsing in parse_calendar_symbols() might be a bit more verbose than
it really needs to be, but it is to ensure the symbols are generated in
a known order that we can control with enumerations.
|
|
This was an oversight in e42d954743056e476bbb1623cfc60e7797a8a6ca.
These fields should always follow the locale preference in the CLDR.
Overriding these fields would permit formats like "h:mm:ss" to result in
strings like "1:2:3" instead of "1:02:03".
|
|
TR-35's Matching Skeleton algorithm dictates how user requests including
fractional second digits should be handled when the CLDR format pattern
does not include that field. When the format pattern contains {second},
but does not contain {fractionalSecondDigits}, generate a second pattern
which appends "{decimal}{fractionalSecondDigits}" to the {second} field.
|
|
Some callers will want different behavior depending on what field is
being provided to the callback.
|
