profile
viewpoint

issue commentPolymer/lit-html

Discussion: use semantic-release and conventional commits

Checking out what is the latest state of the library is already possible by installing from the master branch on github. Installing packages off a git repo is supported in NPM, but unlike a different package version it is very clear that it is something you should probably never do in a published package.

web-padawan

comment created time in 15 hours

issue commentPolymer/lit-html

Discussion: use semantic-release and conventional commits

I think not releasing often is a feature, not a bug. Lit-html is quite fragile in the sense that applications stop working if for any reason multiple versions of lit-html exist. Because NPM does not really having any features to systematically avoid this, the more often we get new releases the more often things will break.

Also, packages that depend on some kind of pre-release version will be incompatible with packages that depend on a non-pre-release version, by definition. I think it's a terrible idea to have two "official" releases that are incompatible with eachother, it will just lead to fragmentation of the ecosystem.

web-padawan

comment created time in a day

issue openedwebcomponents/polyfills

Stylesheet link support

The following syntax is allowed in the Web Component v1 specification and currently works correctly on Chrome and Safari:

<template id="element-template">
  <link rel="stylesheet" href=style.css">
  <div>...</div>
</template>

At the moment, this polyfill only seems to support inline style tags. Is support for link tags in the pipeline, or will it remain unsupported?

created time in 9 days

issue commentPolymer/lit-html

Add syntax for spreading attributes, properties, and event listeners

We're currently deciding if 5% additional library size is a good tradeoff for adding a spread feature, and opinions are divided on this point.

I think it will be very difficult to get broad support for significantly increasing the library size, only to make a minor change to the syntax.

Everything in software is a tradeoff. Making changes is not always progress.

straversi

comment created time in 22 days

issue commentPolymer/lit-html

Add syntax for spreading attributes, properties, and event listeners

The equals sign is not optional, because of how the parser works. The spread is interpreted as a special case of an attribute, which requires the equals sign.

Supporting the spread without equals sign would require changes to the parser.

straversi

comment created time in 23 days

issue commentPolymer/lit-html

why lit-html is not transpiled to es5 in npm?

Remember that you do not need to move your entire project to es6 to use es6-based dependencies.

maciejw

comment created time in 23 days

push eventruphin/auto-pass

Goffert van Gool

commit sha 0b5d9593eeb2733928c1561f403f948c40d1cdec

Fix container name

view details

push time in 24 days

push eventruphin/proxy

Goffert van Gool

commit sha cba2bd970e41199f85100266e2202c2169bf7b34

Add auto-pass

view details

push time in 24 days

push eventruphin/auto-pass

Goffert van Gool

commit sha 0d12ff5f8ef31e207de25127456850d682437ace

Add demo

view details

push time in 24 days

issue commentPolymer/lit-html

Add syntax for spreading attributes, properties, and event listeners

The current proposed implementation is a builtin, so it is not optional.

straversi

comment created time in 24 days

issue commentPolymer/lit-html

Add syntax for spreading attributes, properties, and event listeners

Personally, this feature feels like syntax sugar to me, and I don't think it adds significant new capabilities to the library. I'd welcome this as a directive, but I'm not sure adding additional overhead to the core library is worth it to me. I understand the use case of having a dynamic set of properties, and wanting to keep a declarative format. However, I have not encountered this case in any of the the projects that I have worked on, so that makes me feel like it's not a common case. To me, this change will effectively be 5% additional overhead.

I did encounter several developers who would like to use spread operators in their templates, not because their properties are dynamic, but simply because they like the style. I do expect that when this feature is added, that a significant number of developers will adopt this as a default way to bind their properties for that reason. If this feature has a performance cost compared to normal static bindings (which I believe it does), that may be an additional reason to be careful with adding this feature. Having different ways to do the same thing is generally not a great pattern in software.

straversi

comment created time in 24 days

issue commentw3c/csswg-drafts

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

A simple scenario to explain why scope needs to be inherited is this:

Say a webpage defines a "my-font-family" font in the global style, and sets this font on the body, effectively setting that font to be inherited by all elements on the entire page. Somewhere on the page is a webcomponent, which inside it's shadowroot also defines a "my-font-family", and sets that font to be used on one of it's elements (but not all). If the scope would not be inherited, all of the elements inside the custom element would now use the font defined in the shadowroot, which is clearly not intended.

If the scope would not be inherited, there is risk of naming collisions, and custom element authors would have to start namespacing their font names to avoid collision with other fonts defined in it's parent scopes. This is clearly not desired.

Can you provide a concrete example where the system with scope inheritance does not work as you expect it to?

tabatkins

comment created time in 25 days

push eventruphin/auto-pass

Goffert van Gool

commit sha ec2e57039e5b9fa4d1e3f86dc803143cd04aaef1

Refactor

view details

push time in 25 days

issue commentPolymer/lit-html

Add syntax for spreading attributes, properties, and event listeners

The updating mechanism for this is fundamentally different from how current property/attribute setters work. How will caching/updating things work? What if you spread one less property than in the previous render, does it remove the property from the node? Does it remember the previous value for every property ever spread indefinitely, so it can do updates only when the values changed?

straversi

comment created time in 25 days

create barnchruphin/auto-pass

branch : master

created branch time in a month

created repositoryruphin/auto-pass

A tiny library to make password managers work with Shadow DOM

created time in a month

push eventruphin/dotfiles

Goffert van Gool

commit sha 535d8442aacc00d060d3c283c0deae2609cd2827

Add default zoomlevel to vs code settings

view details

push time in a month

push eventruphin/dotfiles

Goffert van Gool

commit sha ab218191c5c760f67d03ea2d15c964118fd81eb9

Add default zoomlevel to vs code settings

view details

push time in a month

push eventruphin/dotfiles

Goffert van Gool

commit sha 3aaa0b3eb4d99abb09c2c1b0a4de4b6b5c102f17

Tweak vs code settings

view details

push time in a month

create barnchruphin/dotfiles

branch : master

created branch time in a month

created repositoryruphin/dotfiles

A collection of settings and other relevant files

created time in a month

issue commentPolymer/lit-html

The position of the slash of self-closing tag will change render result

Ah yes, I did not see the missing surrounding quotes. I would say the current behaviour is arguably correct.

The most obvious way to avoid this problem is to omit the solidus (/), as it is not required for self-closing tags, and in fact has no special meaning in HTML.

BlackGlory

comment created time in a month

issue commentPolymer/lit-html

The position of the slash of self-closing tag will change render result

Looks like a bug.

What version did you encounter this with, and have you tested if this still happens with the current master branch? I think there have been some improvements to the parser since the last release, so it may have been fixed already.

BlackGlory

comment created time in a month

issue commentPolymer/lit-html

[feature request] add update to a TemplateResult

It is very possible to implement something that looks very similar to your example:

class CookieFactory {
  constructor() {
    this.renderTargets = [];
    this.clickCount = 0;
  }
  addRenderTarget(target) {
    this.renderTargets.push(target);
  }
  
  get template() {
    return html`
    <style>
      #cookie {
        width: 100px;
        height: 100px;
        background-color: red;
      }
    </style>
    <div id="cookie" @click="${this.click}"></div>
    <div>count : ${this.clickCount}</div>
  `
  }
  
  click() {
    this.clickCount += 1;
    this.update();
  }
  
  update() {
    this.renderTargets.forEach(target => {
      render(this.template, target, {eventContext: this} )
    })
  }
}

const thing = new CookieFactory();

thing.addRenderTarget(document.getElementById('one'));
thing.addRenderTarget(document.getElementById('two'));
thing.update();

Is this a good idea? I don't know. It works in this toy example, but when the content becomes more complex it will quickly become pretty fragile. I'd recommend using some base class like Gluon or LitElement. You can find two different implementations here: https://codepen.io/ruphin/pen/PvoebW?editors=1010 (as you can see, no compilation steps)

vdegenne

comment created time in a month

fork ruphin/lit-element

A simple base class for creating fast, lightweight web components

https://lit-element.polymer-project.org

fork in 2 months

issue commentPolymer/lit-html

Template with = in text causes malformed TemplateResult

There are currently several proposals to parser changes that solve this problem, but we are waiting with changes to the parser system until the benchmarking solution is in place so we can account for performance impact.

LarsDenBakker

comment created time in 2 months

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 2 months

push eventruphin/webdev

Goffert van Gool

commit sha 14b08895b3ce198ab03457af487114fa6109320b

Install gosu through apt; add flag to skip npm install

view details

push time in 2 months

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 months

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 months

push eventruphin/lite-html

Goffert van Gool

commit sha 4cb1d14f5a1f18a503fadd37220db7e852b76b30

wip

view details

push time in 2 months

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 2 months

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 2 months

create barnchruphin/lite-html

branch : refactor_template_parser_dos

created branch time in 2 months

PR opened open-wc/open-wc

Update README.md

Fix typo

+1 -1

0 comment

1 changed file

pr created time in 2 months

push eventruphin/open-wc

Goffert van Gool

commit sha cd5250aad04cb70962b133e3ef8a49684728df3f

Update README.md Fix typo

view details

push time in 2 months

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 2 months

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 2 months

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 2 months

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 2 months

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 2 months

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 2 months

issue commentw3c/webcomponents

Web Components F2F Spring 2019

I would prefer a vegan option if available

rniwa

comment created time in 2 months

create barnchruphin/skeleton

branch : master

created branch time in 3 months

created repositoryruphin/skeleton

A skeleton for Web projects

created time in 3 months

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 3 months

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 3 months

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 3 months

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 3 months

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 3 months

push eventruphin/lite-html

Goffert van Gool

commit sha abe9061f239a459eb348c944e595a032f995ee26

wip

view details

push time in 3 months

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 3 months

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 3 months

push eventruphin/lite-html

Goffert van Gool

commit sha 69cabedf51dca25e332e35850253f48e3510c0e3

wip

view details

push time in 3 months

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 3 months

issue commentw3c/webcomponents

Web Components F2F Spring 2019

I would like to attend.

rniwa

comment created time in 3 months

create barnchruphin/lit-html

branch : wip

created branch time in 3 months

push eventruphin/lit-html

Goffert van Gool

commit sha 9221cf47b9ec317110d62f133179984f07cf9c9a

Correctly handle part insertions

view details

push time in 3 months

push eventruphin/lit-html

Goffert van Gool

commit sha c309d8552ea728999fbbaf5d2fe642c1ce3c2e13

Correctly handle part insertions

view details

push time in 3 months

more