issue commentw3c/webcomponents

Web Components F2F Spring 2019

For those who are already in Toronto, perhaps we can meet this evening for dinner / drinks somewhere downtown. :)

rniwa

comment created time in 5 hours

push eventruphin/webdev

Goffert van Gool

commit sha 14b08895b3ce198ab03457af487114fa6109320b

Install gosu through apt; add flag to skip npm install

view details

push time in 17 hours

issue commentw3c/webcomponents

How to handle non-type=”module” scripts in HTML Modules?

A side-effect of removing the type="module" declarations from scripts in an html module file is that the html file itself may become invalid (when loaded directly as an HTML file, not as a module), because in this scenario the scripts will not be interpreted as module scripts. By going through with this, you are essentially creating two classes of *.html files; one that may be opened directly in a browser and one that may only be loaded as a module.

I'm not sure how much of a concern that is, but I think it is worth considering.

travisleithead

comment created time in 2 days

issue commentw3c/csswg-drafts

[css-scoping] Handling global name-defining constructs in shadow trees

Variables (that is, custom properties) have no relevance here. They're already correctly element-scoped+inherited, so there's no sense in which scoped() can apply to them.

I was using the shorthand term of variables to refer to global name-defining constructs, which I incorrectly assumed was clear from the context of this discussion, but I digress :)

Perhaps it is a good idea at this point to summarise the current proposal in its entirety, which I will attempt below.

Proposal summary

Definition of Terms

Name-defining construct Any CSS rule that creates a new 'name' that values can refer to, such as @font-face or @keyframes.

Named value Any CSS property value that refers to a 'name' that can be defined using a name-defining construct, such as values of font-family and animation-name.

Rules

CSS name-defining constructs (@font-face, @keyframes, etc) define those names in the nearest enclosing ShadowRoot or Document of the <style> node or constructed stylesheet that contains the name-defining construct.

CSS named values should resolve by looking up the name in the nearest enclosing ShadowRoot or Document of the <style> node or constructed stylesheet where the name was used.

If a CSS named value is set through the .style property of a Node, the nearest enclosing ShadowRoot or Document of that node shall be used to look up the value instead.

If a name is not defined in a scope, a recursive lookup should find that name through the containing shadow tree hierarchy up to the document (similar to CSS variables).

The internal representation of a named value consists of a name and scope. The scope is a ShadowRoot or Document object and refers to a shadow tree or document where the name should be looked up.

Serialising a named value (through getComputedStyle or other methods) is unchanged, which means it returns only the name, and scope information is lost.

When retrieving a named value through TypedOM, both the name and scope component will be available through name and scope properties.

When setting a named value through TypedOM, a specific scope can be provided, which overrides the default of the nearest enclosing ShadowRoot or Document of the element.

For CSS properties that are inherited through shadow tree boundaries (such as font-family) the inherited value retains the original scope.

Open questions

  • What happens when CSS documents are loaded in through <link rel="stylesheet"> elements inside a shadow tree?

    • Do name-defining constructs in that CSS document re-define the name inside that shadow tree?
    • Do properties using named values look up the names again in the context of that shadow tree?
  • How to name the property that refers to the lookup location of a CSS named value in a TypedOM CSS property value

    • Candidates: .scope, .source, .context
  • What happens when an element has a style with a named value set with the default scope of the nearest enclosing ShadowRoot or Document, and that element is moved to another document or shadow tree? Does the named value retain it's original scope, or does the scope change to the new location?

Known issues

When using traditional (non-TypedOM) methods to retrieve a named value, some information is lost. This means that reading and setting the same value may have the side-effect of changing the scope component of an element's style, e.g. el.style.fontFamily = el.style.fontFamily is not side-effect free.


In order to make sure we are not missing some edge cases, it would be nice to have complete lists for:

  • All name-defining constructs

    • @font-face, @keyframes, ...?
  • All CSS properties that use named values

    • font, font-family, animation, animation-name, ...?
tabatkins

comment created time in 2 days

push eventruphin/lite-html

Goffert van Gool

commit sha 4cb1d14f5a1f18a503fadd37220db7e852b76b30

wip

view details

push time in 3 days

issue commentw3c/csswg-drafts

[css-scoping] Handling global name-defining constructs in shadow trees

Some other side effects of omitting some kind of an explicit (scoped) notation are:

It will be impossible to write an inline style declaration that refers to a variable that exists in an outer scope but is overridden in the scope of the element's shadow tree. I expect this to be extremely rare, and there exists an easy workaround of re-defining the outer variable with another name.

If the inline style declaration is always scoped to the shadow tree scope of the element, it will be impossible to write an inline style declaration on a slotted element that refers to a variable defined inside the shadow tree it is slotted into. This leads to a weird situation where if a slotted element is assigned a style from within the shadow tree (with some ::slotted() CSS selector), and that style is copied verbatim to the element's inline style (say through the browser inspector), it will change in behaviour. Again, I expect this to be extremely rare.


I agree with @rniwa that we should optimise for common usecases and scenarios first. The proposed model seems consistent from a developer's perspective, and most of the issues mentioned only arise when existing objects are modified imperatively by an external force. In those cases there is always an alternative more heavy-handed solution to solve the same problem, and I don't think we can get to a perfect level of consistency that includes all these edge scenarios without sacrificing ease of use (by introducing additional syntax).

tabatkins

comment created time in 7 days

issue commentw3c/csswg-drafts

[css-scoping] Handling global name-defining constructs in shadow trees

The behaviour described by @rniwa is what currently happens in all browsers for the @keyframes global name (See https://codepen.io/ruphin/pen/pBpxvx). I think this is the most expected and reasonable behaviour, and @font-face should probably behave in a similar way.

Regarding inheritance and variables leaking outside the shadow tree; this is already the case currently. Custom Elements are able to style direct descendants from styles defined in the shadow root, and they can add any style to a direct child, including styles that are inherited. (e.g. font-family: monospace). I don't think this is considered 'leaking out' of the shadow tree, otherwise the ability to style descendants would not be part of the spec in the first place. It makes sense that for any styles that are inherited, the complete style is inherited, which in this case includes the correct reference to the correct @font-family.


There is still the question of what happens to slotted content. Currently this is the only feature that exhibits inconsistent behaviour between browsers. The complexity is that when the element is assigned a style (say, animation) that refers to a global variable (in this case @keyframes), it is not clear which scope it should find this variable.

In my opinion the only reasonable behaviour is to look up that variable in the scope where the original style was assigned (in this case wherever the animation style was assigned). Safari correctly does this, but Chrome and Firefox look up the variable in the scope of the element itself which is always outside the shadow root.

The most obvious argument why the behaviour implemented by Chrome and Firefox is wrong, is that it is literally impossible to animate slotted content using @keyframes definitions without polluting the global scope.


Personally I never understood the need for a scoped() function. The only purpose would be to allow a global variable to be used in a shadow tree instead of the local one, but since the Custom Element implementer has full control over the shadow tree, this can effectively already be done by naming the local variable differently.

tabatkins

comment created time in 8 days

create barnchruphin/lite-html

branch : refactor_template_parser_dos

created branch time in 12 days

PR opened open-wc/open-wc

Update README.md

Fix typo

+1 -1

0 comment

1 changed file

pr created time in 16 days

push eventruphin/open-wc

Goffert van Gool

commit sha cd5250aad04cb70962b133e3ef8a49684728df3f

Update README.md Fix typo

view details

push time in 16 days

fork ruphin/open-wc

Open Web Components provides a set of defaults, recommendations and tools to help facilitate your Web Component.

https://open-wc.org/

fork in 16 days

push eventruphin/lit-html

Justin Ridgewell

commit sha 1a51eb54edf883e02e640bbaee24297c61d6fd69

Fix tests in Chrome 41 (#853) * Use getter to override HTMLTemplateElement.content Chrome 41 doesn't like to override the `content` if it's a data descriptor. A getter works fine, strangely. * Use appendChild to avoid an infinite loop in ShadyDOM It has some weird bugs...

view details

Justin Fagnani

commit sha 27ae4541edf2426b814ed9d80be418d9608afaae

Revert the change to template instance clone/upgrade ordering to fix Safari. (#876)

view details

Peter Burns

commit sha 06f6eead073990235861db3be23dfcd412b331b0

Mark fields as readonly where possible. Likewise use ReadonlyArray. (#749) * Mark fields as readonly where possible. Likewise use ReadonlyArray.

view details

Steve Orvell

commit sha 32b42a3f934d959d2666f9e896a76aa5f85d431b

Prevent empty styles from causing problems in `shady-render` (#864) * Prevent empty styles from causing problems in `shady-render` Fixes #760. ShadyCSS eliminates empty styles. This caused 2 problems in `shady-render` when using native Shadow DOM: 1. When re-adding the style to the rendered content, the code assumed a style would exist after ShadyCSS handled the content. It now checks. 2. When modifying the lit template used for subsequent renders, the style could be eliminated. This would break node ordering. A dummy style is now inserted in this case. * Update CHANGELOG.md Co-Authored-By: sorvell <sorvell@google.com> * Update comment in src/lib/shady-render.ts Co-Authored-By: sorvell <sorvell@google.com> * Address review feedback. * Simplify logic slightly * Fix typo * Format.

view details

Keanu Lee

commit sha 6e44c7f0b84a326da408bcd8126fea2587a4dca1

[docs] Remove z-index on alert style

view details

Peter Burns

commit sha c9bcd4265ad151a9d1b14794bc549e103c2f667d

Update to typescript latest (#879)

view details

Arthur Evans

commit sha 7f909e364f8f6723698ac8c3a674cd243a4420f3

Add Creating directives doc. (#874) * Add Creating directives doc. * Addressed feedback.

view details

Patrick Shaw

commit sha 33fd1969edb6dc3c6007ed0a9b2759b2e3c70ac5

Typo: Fixed HTML capitalisation (#878) The L in HTML wasn't capitalised in SVGTemplateResult's class comment :3

view details

AnthumChris

commit sha 5e5383b2102195f7d8ace756ec903f6e231fdcda

Fix typo on home page (#869)

view details

Christian24

commit sha 28d483927f490d0f3675c1e7ee1b069696637af3

Document how to render no content (#785) * Draft of fixing #784 * Addressed some review feedback: added import for nothing * Addressed some review feedback: added slot fallback content on when to use nothing. * Rephrased the last sentence * Added more information on rendering nothing with empty strings, null or undefined. * Added another example using undefined and added ifDefined comment * Moved section to writing templates * Addressed review feedback * Added a line addressing inconsistency of null and undefined.

view details

Justin Fagnani

commit sha ef71ba372c64190d010f82f539fdca7da8dd7905

Fix bindings in comments (#882)

view details

Michael Stramel

commit sha 93591632a669a3d64127da7a7e87f5310aff5b95

Remove typing from noChange (#856)

view details

Peter Burns

commit sha 45a87e88713b241d23cddb4910f17b4b416985d4

Typo: fix common misspelling (#865) Yet another minor lint warning that keeps bugging me

view details

Michael Stramel

commit sha 794030d4e9a93775952d6aded361ab5ddd018c0b

set this.value conditionally (#857) Move setting this.value into the value changed branch for boolean attributes

view details

Justin Ridgewell

commit sha e3dccbe39c67ac9c164c1f633d8a8504e26cc62d

Fix attribute-like text rendering "$lit$" (#855) Also gives us a chance to use a faster check when looking for bound attributes, since we're already paying for the bytes. Fixes #854

view details

Justin Ridgewell

commit sha 9019c1edc57b454c81408c8b76f75c8d12c666ba

Shorten lastAttributeNameRegex a bit (#850) The Unicode control characters include all space characters except " ". So the attribute name character class doesn't need to include them, they're already part of the `\x-\x1F` range.

view details

Justin Ridgewell

commit sha 9c6240a68aaccd1229b62d6fe237db16ce1aa6f3

Mangle private properties (#859) This enables mangling of private properties by giving them the `__foo` naming convention. Really, that's just to distinguish them from the protected `_bar` pattern that was introduced with the Part APIs.

view details

Justin Ridgewell

commit sha 0c23632f6ea9a1d2f50aded1919e81d2c0561be1

Fix rendering comment binding followed by attribute (#845) We forgot to update the `partIndex`, so when the attribute tried to execute the `lastAttributeNameRegex` on the last string (determined by the `partIndex`), it would fail to match anything. I'm guessing this will fix #613.

view details

Justin Ridgewell

commit sha 61c08a615abadbe58bc3cc06edaab1e8e4aa094d

Early exit template creation (#849) We know how many parts are in the template by the number of values that the `TemplateResult` is holding. So, when we've found that many parts, we can stop traversing the template tree and go back to rendering that DOM.

view details

push time in 17 days

issue commentruphin/slidem

FF: revealed content displays under previous steps

Found the problem. The zero-md element has a style contain: content that is not recognised on non-chrome browsers. This is also why the top and bottom padding disappears in the markdown frame. If this rule is removed, Chrome behaves the same as the other browsers.

It's trivial to fix, the zero-md element just needs a classic overflow: auto or overflow: hidden as a fallback to the newer content CSS rule.

Super nice deck! :)

bennypowers

comment created time in 18 days

issue commentruphin/slidem

FF: revealed content displays under previous steps

Neat! I love cross-browser compatibility issues. Digging right in :)

bennypowers

comment created time in 18 days

issue commentPolymer/lit-html

Exec lastAttributeNameRegex only once per template string

The parser/template instantiation system I'm working on fixes this issue. It annotates the bound attributes during initial template creation, as suggested here.

justinfagnani

comment created time in 19 days

issue commentw3c/webcomponents

Spring 2019 F2F Agenda

For real world use cases I may be able to provide some insights from the perspective of ING, particularly in the area of accessibility.

rniwa

comment created time in 19 days

issue commentw3c/webcomponents

Web Components F2F Spring 2019

I would prefer a vegan option if available

rniwa

comment created time in 19 days

create barnchruphin/skeleton

branch : master

created branch time in a month

created repositoryruphin/skeleton

A skeleton for Web projects

created time in a month

issue commentPolymer/lit-html

Values changed outside of lit-html rendering are not updated from lit-html

How will the directive work in multi-part attributes?

justinfagnani

comment created time in a month

issue commentPolymer/lit-html

Using constructors as tag names

The reason LitHTML is fast is because it uses mostly native capabilities to do rendering, and does not have to build virtual trees. However, there is no Element.changeTag()-like API in the platform. If you want to change a node type, you have to re-render that node and all it's content. Even the most advanced implementation using some form of templateString-caching as suggested by @luwes is indistinguishable performance-wise from switching between different static templates (when the dynamic tag changes).

VirtualDOM lends itself to this type of rendering, and if you wish to use dynamic tags, you will probably get more efficiency out of VirtualDOM rendering techniques.

If you want to get that same level of efficiency with LitHTML, you will have to implement a more complex re-parenting scheme as described higher up in the thread, at which point you are essentially re-implementing functionality from VirtualDOM-like renderers. It is not technically impossible, but implementing something like that is way beyond the capabilities of most users, and far more advanced than the solutions suggested in this thread.

As an aside, the performance cost of naive implementations right now is probably not very high, but this is because of a bug in Safari that causes the object ID of StringsArrays to occasionally change. To solve this we have a fallback key mechanism that checks for string equality, which means that naive implementations get "caching" for free right now (the key comparison/lookup is still strictly slower). Once Safari has been fixed and the workaround is removed from LitHTML, these implementations will suddenly stop working and lose all caching capabilities, which means they will fully re-build the templates and re-render the DOM on every render call, even if the tag stays the same.

Even when some kind of cache is implemented correctly (which is not trivial), changing the value of a tag will still cause all the nodes in the template to re-render, including the static ones, which breaks user expectation. This breaks all templates with input elements in their static content. Right now this is safe because regardless of dynamic values inserted by LitHTML, the static parts of the template are unchanged. If you have a dynamic tag anywhere inside the template, all nodes will be destroyed and recreated when the dynamic tag changes, which destroys all state of the input elements (like the value, or the fact that they may currently be the active/selected element).

These are all implementation details which normal users are not expected to be aware of or understand. This is why I think it is important that average users don't get the idea that using dynamic tags is "fine" or even a consideration. The risk is average users googling how to use dynamic tags, landing on a thread like this with naive implementations that seem to solve their problem, and them using it without understanding the implications. There are other solutions than dynamic tags to solve the problems that users have, and they should look into those instead.

treshugart

comment created time in a month

issue commentPolymer/lit-html

Using constructors as tag names

Yes, it is possible to a degree, but this requires a specific implementation that none of the above examples include.

It also means that when the dynamic tag changes, the entire template is re-rendered, which is not what developers expect coming from React or similar environments. This is why I think it is a bad idea to promote this pattern in general, because it breaks expectations of what lit-html does.

Experienced developers with very specific use cases may find a purpose for this, but for general public this pattern should not be promoted in any way.

treshugart

comment created time in a month

issue commentPolymer/lit-html

Using constructors as tag names

Note that constructs like this disable the ability of lit-html to effectively cache your templates, which means that on every re-render, it will destroy the DOM and rebuild it from template. Dynamic tags are not supported by lit-html for this reason.

Just leaving this warning here since people seem to keep finding this thread. I strongly recommend NOT to do anything like this, unless you have a VERY good reason to do so. Your rendering performance will degrade significantly when you do this.

treshugart

comment created time in a month

issue commentPolymer/lit-html

Make `shady-render` smaller by by moving functionality into ShadyCSS

What is the benefit of moving the complexity elsewhere? Won't that just bloat ShadyCSS for all non-lit-html users? Or is there a significant amount of duplicate code that can be eliminated by merging the codebases?

sorvell

comment created time in a month

push eventruphin/lite-html

Goffert van Gool

commit sha abe9061f239a459eb348c944e595a032f995ee26

wip

view details

push time in a month

issue commentw3c/webcomponents

Spring 2019 F2F Agenda

It is a very small edge-case that is currently unspecified in the specs, but it can be resolved without touching larger issues like scoping of css name defining constructs.

I think it is trivial to demonstrate that the Safari implementation is correct. It is currently impossible to apply animations to slotted content in Chrome and Firefox due to this.

If I have five minutes to make the case, I am sure we can get a consensus on it, so we can suggest a possible resolution to the csswg.

rniwa

comment created time in a month

issue commentw3c/webcomponents

Spring 2019 F2F Agenda

It is this mentioned in this issue: https://github.com/w3c/csswg-drafts/issues/1995 Although I think that issue got somewhat derailed into a larger discussion on handling of name-defined constructs in shadow trees.

I'm only concerned about the current incompatibility between Safari and Chrome/Firefox regarding the lookup scope of name-defined constructs for slotted content.

A minimal reproduction of the issue is here: https://codepen.io/ruphin/pen/zPQvXw

rniwa

comment created time in a month

push eventruphin/lite-html

Goffert van Gool

commit sha 69cabedf51dca25e332e35850253f48e3510c0e3

wip

view details

push time in a month

issue commentw3c/webcomponents

Spring 2019 F2F Agenda

What does the 'outstanding issues' list look like, and is there a way to put items on this list? There is a small outstanding compatibility issue I reported a year ago that needs some kind of resolution, and can hopefully be resolved in a few minutes.

rniwa

comment created time in a month

issue commentw3c/webcomponents

Web Components F2F Spring 2019

I would like to attend.

rniwa

comment created time in a month

create barnchruphin/lit-html

branch : wip

created branch time in a month

push eventruphin/lit-html

Goffert van Gool

commit sha 9221cf47b9ec317110d62f133179984f07cf9c9a

Correctly handle part insertions

view details

push time in a month

push eventruphin/lit-html

Goffert van Gool

commit sha c309d8552ea728999fbbaf5d2fe642c1ce3c2e13

Correctly handle part insertions

view details

push time in a month

push eventruphin/lite-html

Goffert van Gool

commit sha f61b3a1241704160c759703e21ea84f938bf4152

wip

view details

push time in a month

issue commentPolymer/lit-html

how render <input pattern="${pattern}">

You may want to look at the ifDefined directive: https://lit-html.polymer-project.org/guide/template-reference#ifdefined

The ifDefined directive will render the attribute if the value passed in is not undefined. However, it will not work for falsy values.

If you want conditional rendering based on truthyness, you can make your own directive that does this:

import {AttributePart, directive, Part} from '../lit-html.js';

const ifTruthy = directive(value => part => {
  if (value && part instanceof AttributePart) {
    if (value !== part.value) {
      const name = part.committer.name;
      part.committer.element.removeAttribute(name);
    }
  } else {
    part.setValue(value);
  }
});

render(html`<input pattern="${ ifTruthy('') }">`, document.body);
// renders: <input>

render(html`<input pattern="${ ifTruthy('something') }">`, document.body);
// renders: <input pattern="something">
mantou132

comment created time in a month

push eventruphin/lit-html

Goffert van Gool

commit sha efaa539177a219984f5bdf4dfdea8130c93c8e26

Clean up marker nodes

view details

push time in a month

push eventruphin/lit-html

Goffert van Gool

commit sha bc28a60e90fb40906e3e01c57148b468d42cae92

Format

view details

push time in a month

PR opened Polymer/lit-html

[WIP] Refactor template parser

This is a refactor of the template parsing system. It is a work in process, making this PR solely for testing purposes.

+579 -764

0 comment

14 changed files

pr created time in a month

create barnchruphin/lit-html

branch : refactor_template_parser

created branch time in a month

push eventruphin/lite-html

Goffert van Gool

commit sha 9e3dbd10173beaff8ab1d2aa907704b9ba1aa74d

Introduce part committers

view details

push time in a month

issue commentmdn/sprints

CustomElementRegistry.upgrade() documentation is missing

I made a small correction to the description, but I'm not sure if the wording is correct.

ruphin

comment created time in 2 months

push eventruphin/lite-html

Goffert van Gool

commit sha e3fa871c27d87255b51f6601d5c75390c759b734

Refactor new template parser

view details

push time in 2 months

create barnchruphin/lite-html

branch : refactor_template_parser

created branch time in 2 months

pull request commentPolymer/lit-html

Rework TemplateInstance cloning

Here is a very crude proof of concept: https://codepen.io/ruphin/pen/jJVpNa?editors=0010 It seems to be able to handle almost every weird combination of content that I can throw at it, and correctly parse the context and part type.

It still has one minor issue, it does not insert a marker before nodes with an attribute with "" delimiters, but I should be able to put that in when I clean it up.

It looks like a lot of code, but note that it solves a number of other issues that we currently have workarounds for, for example it removes bound attributes from the template entirely so we don't have problems with IE's attribute rewriting. If we add up all the code for those workarounds and the current implementation, I'm sure we can reach a similar byte size compared to the old implementation.

I have no idea yet about runtime performance. I need to clean this code up and implement a constructor for TemplateInstances and Parts that works with this scheme before I can run any benchmarks.

jridgewell

comment created time in 2 months

Pull request review commentPolymer/lit-html

Rework TemplateInstance cloning

 export class Template {  */ export type TemplatePart = {   type: 'node',-  index: number-}|{type: 'attribute', index: number, name: string, strings: string[]};--export const isTemplatePartActive = (part: TemplatePart) => part.index !== -1;+}|{type: 'attribute', name: string, strings: string[]};  // Allows `document.createComment('')` to be renamed for a // small manual size-savings.-export const createMarker = () => document.createComment('');+export const createMarker = (data: string) => document.createComment(data);

That's surprising, there's like 12 createMarker('') calls so uncompressed the difference is 21 bytes in favour of the default value. I guess ('') compresses really well. :)

jridgewell

comment created time in 2 months

pull request commentPolymer/lit-html

Rework TemplateInstance cloning

I am working on a prototype template parser that uses ideas from this PR to improve the template creation process.

The basic idea is that TemplateFactory (or some other component) uses the TemplateResult StringsArray to determine the type and context of each dynamic value (node, attribute, in-commment, in-style). It constructs an HTML string that contains a minimal set of <!-- marker --> nodes that are previousSiblings to whatever nodes the dynamic parts belong to. It also determines the properties of each dynamic part (attribute name for attribute parts, etc), and outputs an array of Part descriptions that look like this:

{
  type: NodePart,
  index: <n> // n-th marker node
}

{
  type: AttributePart,
  index: <n>, // The attribute binding is on the nextSibling of the n-th marker node
  attributeName: 'attr',
  before: 'string', // The content inside the attribute string before the binding
  after: 'string' // The content inside the attribute string after the binding
}

{
  type: StyleNode,
  index: <n> // The binding is inside the <style> node that is the nextSibling of the n-th marker
  before: 'cssString', // The content inside the <style> node before the binding
  after: 'cssString' // The content inside the <style> node after the binding
}

A Template only needs to hold the TemplateElement constructed with the HTML string, and the above information. With these two values we should be capable to construct TemplateInstances directly and with minimal intervention (only walking comments, no parsing of any content required).

The main complexity is in the HTML parsing that we have to do to figure out the context of these parts, but I believe it is relatively easy to do so. We don't have to implement a 'complete' HTML parser, it only needs to differentiate between different basic contexts (between node tags, inside a node tag between < and >, inside a comment, and inside a style tag). I'm working on a basic implementation for this at the moment, and it seems promising.

I have a hard time judging if this HTML string parsing is going to be more efficient than the current tree walking and parsing, but my intuition tells me that it should be. Especially when considering all the random edge cases we are running into with the current parser.

jridgewell

comment created time in 2 months

pull request commentPolymer/lit-html

Shorten lastAttributeNameRegex a bit

LGTM

jridgewell

comment created time in 2 months

PR opened Polymer/lit-html

Reviewers
Add test for comment bindings

This adds a test that is currently failing due to incorrect processing of bindings in comments:

html`<p>${'foo'}<!-- ${'baz'} -->${'bar'}</p>`;

// renders: <p>foo -->bar</p>

Reproduction: https://codepen.io/ruphin/pen/jJVrXd?editors=1010

+6 -0

0 comment

1 changed file

pr created time in 2 months

create barnchruphin/lit-html

branch : comment_test

created branch time in 2 months

pull request commentPolymer/lit-html

Fix attribute-like text rendering "$lit$"

I grant permission.

jridgewell

comment created time in 2 months

pull request commentPolymer/lit-html

Add test for rendering attribute-like parts

The parser doesn't have to be fully compliant. It just needs to pass along all information it has access to so we don't have to collect this information again.

I'll see if I can brew up a prototype

ruphin

comment created time in 2 months

pull request commentPolymer/lit-html

Add test for rendering attribute-like parts

I don't like the current implementation. I don't understand why we start off with a well-formed StringsArray, only form a blob of HTML where we lose a lot of information, and then proceed to parse all the TextNodes and attributes to get that information back.

I prefer the old implementation, which was similar to this: https://github.com/ruphin/lite-html/blob/master/src/lib/template-parser.js#L49-L90

I think this is an opportunity to create a similar parser that works well with #847, by inserting the correct commentNodes and passing on the relevant information that is required by #847, so we can skip most of the work in the Template constructor as well.

ruphin

comment created time in 2 months

PR opened Polymer/lit-html

Add test for rendering attribute-like parts

This is currently broken:

render(html`<div>foo bar=${ "baz" }</div>`, document.body);

// Produces
 > "foo bar$lit$=baz"
+7 -0

0 comment

1 changed file

pr created time in 2 months

create barnchruphin/lit-html

branch : test_attribute-like_part

created branch time in 2 months

pull request commentPolymer/lit-html

Rework TemplateInstance cloning

Now that I'm reviewing this code, I'm going through the current TemplateInstance cloning and it's quite weird as it is. I have no idea when we started injecting text and parsing TextNodes, but that is completely unnecessary. In fact, there is a serious bug in the template cloning system right now:

render(html`<p>Hello test=${ "something" }</p>`, document.body);

 > "Hello test$lit$=something"

I'm looking into fixing that right now.

jridgewell

comment created time in 2 months

issue openedmdn/sprints

CustomElementRegistry.upgrade() documentation is missing

Request type

  • [x] New documentation

Details

<!-- Tell us about the issue you saw. A clear description, links, and screenshots help us fix it faster. --> The CustomElementRegistry.upgrade() method is missing from documentation.

https://html.spec.whatwg.org/multipage/custom-elements.html#dom-customelementregistry-upgrade

I can write up a draft for this documentation page, but I do not have the required rights to create new pages.

created time in 2 months

push eventruphin/lit-html

Keanu Lee

commit sha c96d38f5624ad58260ca1e7d494e996f7ecb4430

Add section indicator in top nav (#835) * Add section indicator in top nav * Override TypeDoc theme underline on hover

view details

Justin Ridgewell

commit sha 1867fd6c0734fbfbe6442dc8e5a0e5316968c18c

Reuse a single TreeWalker in nested templates (#825) Creating `TreeWalker`s isn't very optimized, so reusing a single one in the nested templates can speed it up a bit. https://jsbench.github.io/#d0363ded1753dec3e060e61e1794896b

view details

Justin Ridgewell

commit sha 3fd10481d21ddb3e4ecc2d7cf129de915ef2d90c

Cleanup styleMap directive (#838) - `styleMapStatics` is unnecessary, we can determine if this is the first render by just checking `styleMapCache`. - Use variables for repeated property accesses to save some space.

view details

Justin Ridgewell

commit sha 88f6b7cbac6e8f17726a6fb8dc376c160ac58797

Cleanup until directive (#839) Gets rid of a few useless if checks, and uses an infinity value so we don't have to explicitly check for `undefined`. Also guards against an out-of-bound array access on `previousValues`. I took a bit of liberty with using a 2<sup>31</sup>-1 as "infinity". If you want, we can use the real `Infinity` value.

view details

Justin Ridgewell

commit sha 136c23a502ce9db1717408ba1cef836757106ddd

Cleanup the classMap directive (#837) - The `toggle` polyfill was broken (it didn't toggle 😆). And it was just unnecessary. - `classMapStatics` is unnecessary, we can determine if this is the first render by just checking `classMapCache`. - Use variables for repeated property accesses to save some space

view details

Justin Ridgewell

commit sha 5840b3a5a569b729a53cbd1f6ea7526d3407ceff

Adopt+upgrade template fragments after processing for parts (#831) Importing the node can cause any custom elements to upgrade, and non-compliant custom elements can cause DOM mutations. If this happens before we process the template parts, our `part.index`s walking will be broken. So, it has to wait till afterwards. But we still have to return upgraded elements before the template part's interact with the DOM. Luckily, we just adopt and upgrade them after the processing. Fixes #561.

view details

Justin Ridgewell

commit sha ff9a18ce122271b7cb63f3b2c67aa6679a34f1f7

Optimize TemplateInstance cloning (#827) I'm assuming it's very common to have a large number of nodes in between the template's parts. If so, creating a small inner loop to advance the tree walker should make everything quicker.

view details

Justin Ridgewell

commit sha edd2108ab2dd8b79e47bfda1fa9d55f678c80864

Use tagName when appropriate (#840) Just a small nit.

view details

Abraham Williams

commit sha 5bb11d897add9244c4417c6b9b2b6715263ee74a

Add Homepage URL to package.json (#844)

view details

Justin Ridgewell

commit sha ff65727e4899a81fab05e4c1dde8739b48603b78

Reformat the repeat directive's comment (#842) It was annoying me too much to read it this way.

view details

Сковорода Никита Андреевич

commit sha 40702a0d325120a4891db6f6e67851a9c56aa5c5

shady-render: fix warning formatting (#834) This fixes spaces inside the warning that gets emitted for incompatible ShadyCSS versions.

view details

Justin Ridgewell

commit sha 7c6da93649c8ded5f2d2a0018467d10d8bec6696

Use a stack to create walk nested templates (#828) On the heels of #825, this unrolls our recursive template processor into a stack based one.

view details

Peter Burns

commit sha 9bdf622e1aaaf7f82ccf9d19989a3bd7c13febba

Remove unnecessary type assertions (#846) * Remove unnecessary type assertions This is the result of turning on the no-unnecessary-type-assertion tslint pass and running `--fix`, then fixing up a few tests using `Deferred` and adding an additional assertion in places where TypeScript couldn't infer that a variable was always assigned before being read. I like this lint pass because it makes the code a bit easier to read and understand. I will admit though that I'm proposing this change because we use this lint pass downstream, and it's annoying seeing the lint warnings.

view details

push time in 2 months

Pull request review commentPolymer/lit-html

Rework TemplateInstance cloning

 export class Template {  */ export type TemplatePart = {   type: 'node',-  index: number-}|{type: 'attribute', index: number, name: string, strings: string[]};--export const isTemplatePartActive = (part: TemplatePart) => part.index !== -1;+}|{type: 'attribute', name: string, strings: string[]};  // Allows `document.createComment('')` to be renamed for a // small manual size-savings.-export const createMarker = () => document.createComment('');+export const createMarker = (data: string) => document.createComment(data);

Yes, a default value would be even better

jridgewell

comment created time in 2 months

Pull request review commentPolymer/lit-html

Rework TemplateInstance cloning

 export class Template {  */ export type TemplatePart = {   type: 'node',-  index: number-}|{type: 'attribute', index: number, name: string, strings: string[]};--export const isTemplatePartActive = (part: TemplatePart) => part.index !== -1;+}|{type: 'attribute', name: string, strings: string[]};  // Allows `document.createComment('')` to be renamed for a // small manual size-savings.-export const createMarker = () => document.createComment('');+export const createMarker = (data: string) => document.createComment(data);

Can we use document.createComment(data || '') here so we can drop the '' parameters at most of the createComment calls?

jridgewell

comment created time in 2 months

Pull request review commentPolymer/lit-html

Remove unnecessary type assertions

 export class NodePart implements Part {     if (partIndex < itemParts.length) {       // Truncate the parts array so _value reflects the current state       itemParts.length = partIndex;-      this.clear(itemPart && itemPart!.endNode);+      this.clear(itemPart && itemPart.endNode);

Ah, I see. I thought it functioned like a Safe Navigation Operator. Thanks :)

rictic

comment created time in 2 months

pull request commentPolymer/lit-html

Cache only on the TemplateStringsArray

Overall I'm not a fan of this change. None of the codebases or applications that I have seen ever drop references to templates, so this change would not make any difference other than open up the opportunity for developers to explicitly remove templates from cache, but I don't think there is any demand for this.

Given the temporary nature of the issue, I prefer the current architecture.

jridgewell

comment created time in 2 months

Pull request review commentPolymer/lit-html

Remove unnecessary type assertions

 export class NodePart implements Part {     if (partIndex < itemParts.length) {       // Truncate the parts array so _value reflects the current state       itemParts.length = partIndex;-      this.clear(itemPart && itemPart!.endNode);+      this.clear(itemPart && itemPart.endNode);

Wouldn't this.clear(itemPart!.endNode) also work? I'm not super familiar with TypeScript so it might be functionally different, but it seems more in line with general TypeScript style.

rictic

comment created time in 2 months

issue commentPolymer/lit-html

Attribute parts does not work with hard-coded strings

As mentioned before, lit-html does not process your HTML in any way, and anything outside dynamic bindings is left untouched. This is by design, and it is not an issue.

If you want to assign to properties declaratively, you can absolutely use this:

html`<div .prop=${ "value" }></div>`

This will only set the property once during the initial render, and does nothing on consecutive renders.

kaaninel

comment created time in 2 months

created tagruphin/apex-button

tagv0.0.6

The Apex Legends button

created time in 2 months

push eventruphin/apex-button

Goffert van Gool

commit sha de18d60b0a1964f8cc8cc748c63dd1619a31ef5b

0.0.6

view details

push time in 2 months

push eventruphin/apex-button

Goffert van Gool

commit sha 26157a1aada377ebbc71fc9e2391f528620885aa

Update for web-components listing

view details

push time in 2 months

push eventruphin/lit-html-talk

Goffert van Gool

commit sha 5d52c5acdcae561d3563948bb318fe83270560d8

Change talk url

view details

push time in 2 months

push eventruphin/proxy

Goffert van Gool

commit sha b3a060e826fdc06bc2ca95ab624f0a5eea3a0c8a

Fix typo

view details

push time in 2 months

push eventruphin/proxy

Goffert van Gool

commit sha ad7eaa04bdfc16669a44b13ee20041b8f0286f1c

Add lit-html talk

view details

push time in 2 months

push eventruphin/lit-html-talk

Goffert van Gool

commit sha 7eb0ee9078078eb059f3f815262b3e3c20644cdd

Fix url and build

view details

push time in 2 months

push eventruphin/lit-html-talk

Goffert van Gool

commit sha a2a450804b3c713a7e0dcc16bc08b52bdd697e2e

v1.0

view details

push time in 2 months

push eventruphin/lit-html

Peter Burns

commit sha 6db24ced84fe33bd83a8716507a27c5d15a1ae97

Remove almost all uses of "any" outside of test code. (#741) * Remove all uses of "any" outside of test code. * Format * Give better types for EventPart * Format * Address review feedback. * Address more review feedback. * Get tests compiling cleanly. * Don't use isThenable function. * Add accidentally deleted check. * Revert isIterable, potentially too expensive. * Use EventListenerOrEventListenerObject instead of reinventing it. * Reformat * Use EventListenerObject type.

view details

Arthur Evans

commit sha b5a6ebbd6213cb1344680a6faceb6ca7ae8cc162

Update directive docs (#675) * Update guard directive docs. * Fix typo. * Update template reference. * Update directive reference. * Apply suggestions from code review Co-Authored-By: arthurevans <arthure@google.com> * Address feedback.

view details

Kate

commit sha 9a8796ed1bd1a3d3c7d9513c164eb1c58603a068

Apply theme to API docs (#724)

view details

Keanu Lee

commit sha 5321ed8e2f26d7a90f5d2f74977ccbeb347b70d1

[docs] Add a search box (#753) * Add a search box * Add search box to API docs * Docs search: encodeURIComponent and analytics

view details

Jonathan Bingham

commit sha 74c62e134b9a34d2a243be93b7f4bb0ce2c338a0

Remove line break in comments (#764) One less line in the code block, looks fine on desktop and mobile

view details

Alexander Marks

commit sha 10d11bea4e5f1dc651fff3710f743020f70a2805

Minor fixes to lit-html writing templates docs (#763)

view details

Steven Traversi

commit sha 880631cf8fd7b9dbbfaf792bc8d4c8b7fd5bb1ac

[docs] Update to new Slack logo (#765)

view details

Steven Traversi

commit sha 9916f2f34602bc6f8cb5961751dac90edc655e65

[docs] Improve text, fix typos in Getting Started (#767) * [docs] Improve text, fix typos in Getting Started * Update docs/_guide/01-getting-started.md Co-Authored-By: straversi <straversi@google.com> * Update docs/_guide/01-getting-started.md Co-Authored-By: straversi <straversi@google.com>

view details

Alexander Marks

commit sha 4eb12d963be236ba3499bcc9826321dc7dcc67bb

Update lit-html docs README.md command (#768) * Update README.md Fix a bash command in docs README. * Indent docs block

view details

방성범 (Bang Seongbeom)

commit sha c4a0dbc4e842de4651567b65f71759b1fcc6d7c7

Add a missing bracket (#734)

view details

Steven Traversi

commit sha 96e8ca9b8a1835ae5466d31e491d6039621dcb53

Link to Getting Started from Introduction (#771)

view details

Keanu Lee

commit sha fae97caa027036b95850070a5f637ca23fcebac6

Highlight active link in side nav (#766) * Highlight active link in side nav * Use theme color to indicate active link

view details

Arthur Evans

commit sha d999eacadb00fd237e69378863417933cb63df57

Remove pre-release disclaimers (#773)

view details

Steven Traversi

commit sha 48235f5c1b4085c0edb971807aafea6c3f8bd60a

[docs] Improve text, fix typos in Template Reference (#770)

view details

Keanu Lee

commit sha 7660fd7b7167c013a76e6a4c1cc2dee667ae2065

Use Roboto (#769) * Use Roboto * Load Roboto

view details

Justin Fagnani

commit sha c9c626dc13f5f2197bbedf861aa18646d90569af

Remove stray characters in docs (#777) * Remove stray characters in docs * Fix async* directive descriptions

view details

Fernando Pasik

commit sha efc1a4806c4bd48436b5571613a94d5efa47e102

[docs] open online editors links in new tab (#776)

view details

Arthur Evans

commit sha 10d1dd545da2a856ba2a951b3c94f3d2933ea010

Added Styling & Rendering sections. (#754) * Added Styling & Rendering sections. * Update docs/_guide/03-styling-templates.md Co-Authored-By: arthurevans <arthure@google.com> * Address feedback.

view details

Keanu Lee

commit sha f965fb3b6130267f98d3924b279fc5b2dedb84fc

Don't syntax highlight code in links (#779)

view details

Justin Fagnani

commit sha 153fc5224d2cc0e16ba5d58e2db9dfd242bb5a8b

lint fix

view details

push time in 2 months

pull request commentPolymer/lit-html

Cache only on the TemplateStringsArray

This test is flawed, you're never releasing the tagged template itself. You have to set getTemplateStringsArray to null or place the entire code in a scope that is itself cleaned up. Try on https://output.jsbin.com/wobolap/12/quiet.

I don't quite understand. What I'm seeing is that the key still exists after the timeout: TemplateStringsArray after Timeout true. You are getting the same result judging from the screenshot you posted. Am I interpreting those results wrong?

This change is specifically for Safari. When it's TemplateStringsArray is purged (in error), it'll generate a new Template.

It doesn't. There are two levels of caching, one with the TemplateStringsArray and one with the joined Strings. If Safari purges the TemplateStringsArray objects, the second cache will hit and use the cached Template.

Can you describe a specific scenario where the old implementation does not correctly use a cached Template, or performs more than necessary equality checks? I can't think of one.

jridgewell

comment created time in 2 months

pull request commentPolymer/lit-html

Cache only on the TemplateStringsArray

From a logical perspective, I believe the original implementation was already optimal. In all cases (new template, existing template and equal to previous template, and existing template and not equal to previous template) it performs the minimum number of operations required (where the relevant operations are object equality check, strings equality check, and template instantiation).

The real question is if we want to actively purge from cache any templates that are not currently rendered.

jridgewell

comment created time in 2 months

pull request commentPolymer/lit-html

Cache only on the TemplateStringsArray

I wrote a basic test that checks how WeakMap works with TemplateStringsArrays: https://codepen.io/ruphin/pen/wOwZoY?editors=0011

As far as I can tell, it never clears the key/value pair from the map. Because this refactor still keeps a map of TemplateStringsArrays to Templates, the Templates are still never cleared from memory, which means this refactor effectively does nothing.

jridgewell

comment created time in 2 months

pull request commentPolymer/lit-html

Check if value is primitive in AttributeCommitter

LGTM

jridgewell

comment created time in 2 months

pull request commentPolymer/lit-html

Adopt+upgrade template fragments after processing for parts

The original issue outlined in #561 is that we don't know if the clone-then-adopt approach has a significant performance impact compared to the direct import we have now.

This change does simplify Custom Element handling and fixes several edge cases, but we should get some benchmarks and measure the performance impact before making this change.

jridgewell

comment created time in 2 months

Pull request review commentPolymer/lit-html

Cache only on the TemplateStringsArray

 export class SVGTemplateResult extends TemplateResult {     return template;   } }++export const templateResultsEqual =+    (a: TemplateResult, b: TemplateResult): boolean => {+      if (a === b) {

This should be a.strings === b.strings.

Or better, aStrings === bStrings and placed after the constant definitions below.

jridgewell

comment created time in 2 months

push eventruphin/lit-html-talk

Goffert van Gool

commit sha 751aaa3b8ea371a2ec737854e316e1686ffded9d

Progress

view details

push time in 2 months

create barnchruphin/lit-html-talk

branch : master

created branch time in 2 months

created repositoryruphin/lit-html-talk

A talk on lit-html

created time in 2 months

push eventruphin/slidem

Goffert van Gool

commit sha 72f8c1b6a5bbec5227056e15a771a7582dc194c9

Update dependencies

view details

Goffert van Gool

commit sha 45a1b0b0e0f5b3a7768e858b9c8761c85f4a979a

1.2.7

view details

push time in 2 months

created tagruphin/slidem

tagv1.2.7

Web Component based Presentation Library

created time in 2 months

push eventruphin/gluonjs

Goffert van Gool

commit sha fa81228bfea954e984fde1ab85b138f2af7af2d7

Fix build pipeline, update copyright to 2019

view details

Goffert van Gool

commit sha fcea31a234c515d4da07cfa208387ff6fa75def2

2.5.3

view details

push time in 2 months

created tagruphin/gluonjs

tagv2.5.3

A lightweight Web Component base

created time in 2 months

created tagruphin/gluonjs

tagv2.5.2

A lightweight Web Component base

created time in 2 months

push eventruphin/gluonjs

Goffert van Gool

commit sha e0f5f47dca77b0f97f1e99b31dbfca0d7d3f7563

2.5.2

view details

push time in 2 months

push eventruphin/gluonjs

Goffert van Gool

commit sha d011921e0cc6a4db881947c9900c216024bd65f1

Upgrade and lock package versions

view details

push time in 2 months

push eventruphin/gluonjs

Goffert van Gool

commit sha 54b81453ed4c90bfef0097f511c58d90eaabb258

Update to lit-html 1.0.0

view details

push time in 2 months

push eventruphin/apex-button

Goffert van Gool

commit sha 3660aefe1ff26722c97d9645372333a193d339f4

0.0.3

view details

push time in 2 months

created tagruphin/apex-button

tagv0.0.3

The Apex Legends button

created time in 2 months

push eventruphin/apex-button

Goffert van Gool

commit sha 983533110c93203a78ca8786549e63dfd707005d

Correct relative import for lit-html

view details

push time in 2 months

created tagruphin/apex-button

tagv0.0.2

The Apex Legends button

created time in 2 months

push eventruphin/apex-button

Goffert van Gool

commit sha b1e9e38e0925269836a232dfde27f3886ad77ed4

0.0.2

view details

push time in 2 months

push eventruphin/apex-button

Goffert van Gool

commit sha 829b602ae16c179f1f41f28a1a9cbe7624742630

Set main import to button.js

view details

push time in 2 months

push eventruphin/apex-button

Goffert van Gool

commit sha 62f7626f9175117f73e1a9c28d741d5bff7f2175

0.0.1

view details

push time in 2 months

created tagruphin/apex-button

tagv0.0.1

The Apex Legends button

created time in 2 months

push eventruphin/apex-button

Goffert van Gool

commit sha 93f995fe17afc89dc9b89da457d6075de5bfd753

Package lock

view details

push time in 2 months

push eventruphin/apex-button

Goffert van Gool

commit sha 943a75ee592b28685434c3545f9ea7f76d6a4bb1

Remove unused tasks

view details

push time in 2 months

create barnchruphin/apex-button

branch : master

created branch time in 2 months

more