for context as to why it was changed recently

on a edit form, with a block using the titlefield when loading or resizing the page everything remains visible.

With the CSS above it should work, because it uses calc()

ok, so this only happens when the editor is inside a fieldset

@domihagen does your solution also work for https://github.com/area17/twill/pull/1975 ? I am not a css person myself so I cannot vouch for either solution..

(these tabs look nice @domihagen)

I just tested it locally with an super long title and yes, it works with CSS

I will create a PR

🚀

CSS-Only is also better for Performance. You have a EventListener less. Just as a small note for future: When you use a window.resize EventListener set the option

passive: true

. This tells the browser to not wait for an response of the callback-function.

totally. this was an oversight. thanks @domihagen

Do you mind sharing tabs component with a community? hehe 😄

It´s not a Component. It´s just HTML with a bit of JavaScript

Great. It really looks neat for sure. This can be added to Twill aswell, would be a nice addition.

@domihagen https://github.com/area17/twill/releases/tag/2.12.2

Thank you for your pr!

Hi guys! Does this problem will find solution in nearest future?https://github.com/area17/twill/issues/1957

@BA7YA yes, we're working on it

to confirm, your issue is specifically inside a block, correct? we are seeing a similar issue with conditional fields inside a repeater (outside of blocks)

Yeah. That's problem inside the block, but can be also in other parts (repeaters f.e.x.)

Guys. Do we have any ability to change default tag in Wysiwyg field? Every time when Im filling that fields, it's put my text in tag by default, but I would like to have

that's Quill.js behavior, which is pretty standard amongst wysiwyg editors. It might be possible to default to H1 but that honestly sound like a bad idea, why would you use a wysiwyg to contribute H1 by default? I'd use a standard text field and render its content in an H1, if the intention is that they always use H1

I wanna do that just to avoid one more click 🙂

Recently, I face a problem about different layouts/block sets among languages in same Page, like discussed before: https://github.com/area17/twill/discussions/846 Is there any better idea recently?

Hi @DKC can you share more about your specific use cases? The media field can now be "translated" which wasn't the case when this discussion happened, but not sure that's what you're looking for

I am looking for a page having different blocks selected among languages. For example, looking for: Page Home en: Slider Block Slider Block Album Block Page Home jp: Text Block Album Block Text Block

I see. You may be already aware of this approach, but I'm still going to share it just in case, even though it's not optimal, and if that's not enough for you we can think together on how to implement a fully translatable block editor field because I totally understand the use case. So the approach you can use right now is creating a different record per language by only enabling one language per record in the publish sidebar. That way you can create the blocks you need per language. Now, you maybe don't want to translate all fields outside of your blocks, which would mean duplicating potentially a lot of data which Twill is really meant to avoid. In that case you could use 2 modules, one for fields outside of the blocks editor where you can publish all languages from, and another one for the block editors, related through a browser or parent-child modules. That was a mouthful, sorry 😅

let me know if you have any questions