Gutenberg: Adicionar Bloco: Seção

Eu realmente gosto dessa ideia! Eu também gosto do fato de que tem uma configuração de fundo para ele.

Agradável! E se o bloqueio permitisse as três configurações "avançadas" a seguir:

• Defina um nome de classe a ser serializado nos filhos .child_class, .child_class_1
• Adicione uma primeira classe filha opcional .child_class, .child_class_1, .child_class_first
• Adicionar uma última classe filha opcional .child_class, .child_class_n, .child_class_last

:nth-child seletores

Amei essa ideia. Se as cores de fundo e de texto puderem ser alteradas, pode fazer sentido adicionar cores de link também.

Excelente ideia. Isso irá, literalmente, agregar muito valor ao Editor Gutenberg.

Muito melhor do que apenas o bloco Colunas, que tem muitos problemas. Legal!

Esta é a primeira coisa que decidi criar quando vi que o aninhamento estava disponível. Minha versão é semelhante, exceto que imaginei que você adicionaria o bloco de colunas a ela.

Você tem código para isso disponível?

Se este bloco possui "colunas", devemos apenas atualizar o bloco "colunas". Mas ainda é possível usar um bloco de colunas dentro de um bloco de seção e manter o bloco de seção sem colunas.

Contanto que você não possa colocar blocos de colunas dentro de blocos de colunas 😉

Muitas páginas do site são divididas em seções que possuem conteúdo misto com várias linhas de colunas e, muitas vezes, colunas aninhadas dentro de outras maiores. Este é um exemplo rápido:

Um bloco de seção que age apenas como um invólucro simples, eu acho que seria o mais flexível. (como seria capaz de aninhar blocos de coluna!)

Lançamos um novo projeto de site esta semana. Normalmente ele seria construído com layouts de conteúdo flexíveis de Campos Personalizados Avançados, mas vou ver até onde podemos chegar usando Gutenberg sozinho.

Sim, acho que seções de várias colunas como o exemplo acima de @jvisick não são incomuns. Um contêiner com opções de fundo / texto que aninham blocos seria a abordagem mais flexível. Como agora temos um bloco de colunas em funcionamento, podemos até considerar retirar a opção de coluna deste.

Seria ótimo se houvesse um contêiner interno (div) nesse bloco que contivesse todos os blocos filhos. Este contêiner pode então ser estilizado com max-width e margin-left / right: auto para centralizar os blocos filhos e ter um fundo de largura total.

Ter uma seção de largura total com o conteúdo contido em um layout mais estreito é um padrão de design comum. Estou me perguntando se seria melhor controlado pelos blocos aninhados em vez de embutido no bloco de seção pai.

Acho que um bloco de seção seria muito útil para ... bem, seções em uma página, e concordo que as colunas devem ser um bloco separado (como o que existe agora) que pode ser aninhado em um bloco de seção. Acho que isso é algo que, junto com o bloco de colunas, deve ser incluído na versão do Gutenberg que é mesclada no WordPress 5.0. Se você olhar para os plug-ins de construtor de páginas existentes, as seções são muito usadas, assim como as colunas (obviamente), portanto, incluí-las na versão principal inicial é essencial na minha opinião.

(Eu também acho que é importante que o bloco de colunas obtenha recursos como colunas de largura variável e colunas responsivas, tanto para o bem da experiência central, quanto para tornar mais fácil para os criadores de páginas existentes se reinstalarem fora de Gutenberg, esse é um problema separado.)

Tendo pensado um pouco mais sobre isso, acho que faria mais sentido ter apenas os blocos Seção e Colunas a mesma coisa. Basta adicionar a capacidade de ter apenas uma coluna no bloco Colunas em vez de no mínimo duas. Em seguida, adicione as configurações de plano de fundo deste bloco de seção proposto ao bloco de colunas.

Acho que ter um único bloco de seção / coluna reduziria a quantidade de aninhamento que você teria que fazer. No momento, o bloco de seção proposto nada mais é do que uma área com opções de plano de fundo e largura. Ambos poderiam ser adicionados ao bloco de Colunas, e se o bloco de Colunas permitisse ter apenas uma coluna, não haveria necessidade de um Bloco de Seção.

Além disso, se você quiser uma seção de largura total com conteúdo de largura padrão, isso pode ser feito aninhando outro bloco de Seção / Colunas em outro que esteja definido como largura total. Isso poderia ser feito com uma configuração no inspetor para alterar a largura do conteúdo do bloco, independentemente da largura do bloco inteiro .; isso também pode ser adicionado como alças de redimensionamento visíveis, semelhantes a como as linhas / colunas do Beaver Builder funcionam ou como o bloco de imagens funciona em Gutenberg.

Quanto ao que você chamaria de bloco combinado, acho que apenas manter o nome "Colunas" funciona, já que essa é a função mais óbvia que as pessoas estariam procurando. Não deve ser difícil encontrar as configurações de fundo no inspetor (e eu imagino que seria onde algumas pessoas olhariam em primeiro lugar de qualquer maneira se houvesse um bloco de seção separado e elas não estivessem cientes disso), e usando as colunas bloco como um contêiner de coluna única não deve ser difícil de descobrir, pois o controle deslizante para alterar o número de colunas deve tornar bastante óbvio como fazê-lo ... basta arrastá-lo totalmente para a esquerda.

Mudei de ideia sobre a fusão dos blocos de seção e colunas. Para obter o máximo de flexibilidade com colunas, faria mais sentido que cada coluna fosse seu próprio bloco: um Bloco de colunas. Isso permitiria controlar facilmente as configurações de uma coluna individual, bem como arrastar uma coluna de uma linha para outra. Claro, uma vez que as colunas vão da esquerda para a direita (e agrupadas na maioria dos sistemas de layout), você precisaria que seu bloco pai fosse um que inserisse o conteúdo na direção horizontal e tivesse agrupamento (em vez da direção vertical padrão) e este o bloco pai provavelmente permitiria que apenas blocos de coluna fossem inseridos nele. Este bloco seria uma linha. Esses 2 blocos substituiriam o bloco de colunas. Mas eles não cobrem a situação em que você deseja que várias linhas (geralmente com diferentes números de colunas dentro delas) estejam no mesmo plano de fundo / contêiner, que é o que o bloco de seção faria. Obviamente, o bloco Section nada mais seria do que um contêiner com opções de fundo, preenchimento e largura, e qualquer bloco poderia ser inserido nele. E para layouts mais complexos, blocos de seção podem ser inseridos em blocos de coluna.

Consulte # 6461.

Na verdade, acho que a ideia de no mínimo 1 coluna não é uma solução ruim. Na verdade, se você usar o inspetor para alterar o atributo "min" do controle deslizante para 1 e selecionar um, ele funcionará exatamente como você espera.

No entanto, semanticamente um bloco de seção faz mais sentido de qualquer maneira. O conteúdo interno (ou seja, uma seção de largura máxima dentro de uma seção completa com) pode ser alcançado aninhando duas seções - uma largura de conteúdo dentro de uma largura total.

A ideia da cor de fundo é boa, mas ... talvez um pouco mais específica. Acho que uma abordagem mais genérica seria apenas usar classes personalizadas na seção. O CSS front-end pode capturar isso e quaisquer filhos diretamente.

Após alguma discussão em # 6461, decidi que minha ideia de Bloco de linhas + bloco de colunas não é o caminho certo a seguir. Um bloco de layout semelhante ao de # 5351 (comentário) provavelmente seria muito menos confuso e muito mais flexível. Seja qual for o caso, definitivamente deve haver um bloco de seções, e eu acho que definitivamente deve ser adicionado antes do lançamento do WordPress 5.0.

Quanto às opções de cores de fundo, acho que faz todo o sentido ter opções de fundo em uma Seção. Apenas ter opções de classe parece um pouco restritivo. Freqüentemente, o objetivo do aninhamento em um bloco de seção seria ter várias coisas compartilhando um fundo. Além disso, eu preferiria que outras opções de plano de fundo, como imagens de plano de fundo e planos de fundo gradientes, fossem implementadas, já que essas são geralmente desejadas em vez de planos de fundo de cores sólidas. Blocos de seção aninhados permitiriam até que as cores de fundo fossem aplicadas a um único bloco, o que significa que as opções de cor de fundo no bloco de parágrafo podem não ser mais necessárias.

Quanto ao aninhamento de blocos de seção em vez de ter 2 configurações de largura separadas, acho que pode funcionar. A maior preocupação que eu teria é a quantidade de preenchimento extra que seria adicionado ao aninhamento de blocos de seção, o que leva às opções de preenchimento.

Eu acho que é essencial que o bloco Section tenha a capacidade de personalizar a quantidade de preenchimento que usa, ou pelo menos remover o preenchimento padrão. Claro, isso levanta questões de como você selecionaria o bloco de seção quando outro bloco está aninhado nele. Acho que esse problema será resolvido por melhorias como # 6471 e as coisas que estão sendo trabalhadas no branch try/alternate-hover-approach .

: +1:

Realmente precisamos de um bloco genérico de linha / contêiner, especialmente com configurações de largura.

Idealmente, acho que outras configurações como "Cor de fundo" e "Cor do texto" devem estar em alguma guia de configurações "extras" em cada bloco (além de várias outras configurações CSS geralmente aplicáveis).

No que diz respeito à capacidade de resposta, acho que devemos adicionar um bloco "Responsivo" .

O problema com a cor de fundo e a cor do texto é simplesmente: onde isso termina? Já neste tópico sozinho você tem alguém sugerindo a cor do link. Por que não bordar cor, espessura e estilo? Para ser honesto, preenchimento e margem fazem mais sentido. E quanto a sombra projetada, imagens de fundo, opções de posicionamento e modos de exibição? Estilo e tamanho da fonte, altura da linha e altura mínima? Existem centenas de propriedades CSS e as que você precisa variam em seu design.

Deve ser uma classe, que você pode usar para definir o estilo de

@tmdesigned Termina com o controle WYSYWIG intuitivo e completo de recursos sobre o estilo, a formatação e o layout de uma página da web. Não é esse o objetivo de Gutenberg?

Gutenberg está fornecendo ao mundo um conteúdo WYSYWIG novo, bem planejado, moderno, modelável e extensível ... devemos descobrir o quanto queremos utilizá-lo agora ou perderemos o barco.

A ideia no final é reduzir a quantidade de trabalho que estamos fazendo agora, seja escrevendo CSS, escrevendo sobreposições de CSS hacky ou fazendo tarefas de conteúdo repetitivas.

Nem tudo pode ou deve ser definido com classes, especialmente se forem classes mal direcionadas ou atributos não substituíveis.

Pegue uma configuração numérica definida pelo usuário, por exemplo. Seria muito difícil definir uma classe para cada valor e um desenvolvedor de bloco pode ficar tentado a apenas injetar o valor diretamente no atributo style .

Se ele existir como um bloco e puder ter estilos CSS definidos pelo usuário aplicados a ele, o ideal é que haja um meio unificado e padronizado de fazer isso, mesmo que seja um painel de caixas de texto de pares de chave / valor.

Se desejar, você pode ler meu método sugerido para fazer isso de uma forma que atenda às suas preocupações.

Eu li sua sugestão para uma API e não está muito longe do que eu estava dizendo sobre um gancho adicionado para permitir que pares de valores-chave sejam adicionados.

No entanto, acho que meu ponto original ainda é válido. Como eu disse, existem centenas de propriedades e, embora algumas sejam mais comuns, essa lista vai crescer rapidamente. Podemos ir por esse caminho e tentar encontrar um "bom compromisso", como os recursos do TinyMCE que foram incluídos e removidos do Classic. Mas há muito mais propriedades em jogo aqui, então seria um desafio.

Mas o mais importante, a ideia de adicionar um estilo de nível de bloco direto se desfaz quando você diminui um pouco o zoom e não considera apenas um único bloco. Quando você tem vários blocos semelhantes, em uma página ou entre páginas, você não vai querer inserir todos esses valores novamente. Você vai querer uma abstração ... como uma classe CSS.

Permitir - ou encorajar - o estilo de nível de bloco individual não é ideal porque não é reutilizável. Você está certo em dizer que nem tudo deve ser abstraído em uma classe, mas o CSS foi desenvolvido por uma razão e não deve ser jogado ao vento tão rapidamente.

@tmdesigned Agradeço seu feedback. Acho que entendi a confusão, então tentarei esclarecer.

O objetivo não é eliminar ou mesmo reduzir a quantidade de classes CSS.

O objetivo é, muito especificamente, unificar as configurações de estilo de bloco

Desenvolvedores da Web, desenvolvedores de blocos, desenvolvedores de temas ainda estarão escrevendo código CSS para blocos de estilo e os blocos ainda terão classes, atributos e IDs para que os desenvolvedores possam estilizá-los.

Eles terão exatamente as mesmas classes que têm agora e terão exatamente o mesmo layout que têm agora.

MAS

No momento em que o desenvolvedor do bloco percebe que eles têm propriedades CSS que podem / devem ser configuradas pelo usuário ... é quando Gutenberg assume e decide como esses estilos são injetados (e potencialmente controlados).

Isso resultará em uma única interface comum (para desenvolvedores e usuários) quando se trata de controlar não programaticamente as configurações baseadas em estilo comum do conteúdo da página da web.

Isso dá aos usuários e desenvolvedores um meio único e consistente de visualizar, adicionar, remover, modificar e substituir estilos de bloco que, no final do dia, tudo se resume a propriedades CSS simples.

Desculpe por causar tanto barulho neste tópico. Provavelmente deveríamos avançar a discussão para o assunto relacionado.

Editar nota:

Esqueci de abordar o ponto sobre abstração.

O minuto em que o usuário precisa aplicar exatamente o mesmo estilo ao mesmo bloco exato duas vezes é o momento exato em que as configurações de estilo definidas pelo usuário devem ser abandonadas para as classes CSS (para aquele bloco).

Em outras palavras, as configurações de estilo definidas pelo usuário fornecem um mecanismo consistente para que o usuário personalize os blocos de acordo com sua preferência, seja uma coisa única (como deveria ser) ou 100 vezes em cada página, e como você escolhe estruturar ainda depende totalmente de você.

Acho que quase todos concordamos. Minha sugestão no primeiro post foi ter um gancho para adicionar / remover controles. Não sou contra a personalização de estilos do usuário em nível de bloco, apenas é difícil escolher "aqueles que valem a pena ter por padrão em um bloco de seção genérico" sem que a lista cresça exponencialmente. Ter um mínimo é bom, especialmente se permitir a adição de outros controles. Em qualquer caso, estou surpreso que a margem e o preenchimento não seriam mais universalmente úteis do que a cor de fundo para um bloco de seção.

FWIW, gosto da sua ideia de ter classes geradas como saída, de modo que ainda seja passível de substituição sem ter que usar! Important.

@rchipka @tmdesigned Sei que isso foi há mais de duas semanas, mas você estaria interessado em discutir mais alguns desses detalhes em outra edição? Acho que seria benéfico ter mais olhos neste convo.

Dei outra olhada neste bloco com base nas conversas anteriores.

A maneira mais fácil de compartilhar minhas ideias é por meio de um protótipo: https://wp.invisionapp.com/share/PQJPPAX4JZW

Algumas notas:

• Com base em uma pesquisa rápida: https://wordpress.slack.com/archives/C02QB2JS7/p1527283199000343 Alterei o nome de _Section_ para _Container_.
• Removi as configurações de coluna, pois é razoável que as pessoas queiram misturar e combinar layouts de coluna em uma seção específica, conforme ilustrado por @jvisick.
• Além da cor de fundo, adicionei suporte para imagem de fundo. As configurações são baseadas no recurso existente de imagem de fundo do núcleo.
• Devemos deixar as pessoas aninharem um bloco de contêiner em um bloco de contêiner?

@melchoyce Parece ótimo!

Um recurso interessante que eu gostaria de ver é uma seleção no inspetor para alternar o elemento HTML do bloco entre <aside> , <div> e <section> .

A capacidade de aninhar containers definitivamente deve ser permitida, em minha opinião. Não só seria útil no contexto de ter diferentes áreas coloridas dentro de uma única seção semântica usando a sugestão de elemento HTML sugerida acima, mas também seria útil em situações onde você deseja dar a um único bloco um fundo quando ele não opção de cor de fundo em si.

Outro recurso interessante seriam os fundos gradientes, já que parecem ser bastante populares em alguns designs.

@melchoyce +1 por ser capaz de aninhar contêineres.

@SuperGeniusZeb ser capaz de alterar o elemento HTML também tem estado na minha mente. Talvez uma lista suspensa para escolhas de elementos semânticos?

@jvisick Sim, era nisso que eu estava pensando. O Beaver Builder e o Elementor têm configurações assim para suas linhas / seções.

@melchoyce Acho que os contêineres devem ser infinitamente aninhados. Isso permitirá que os usuários envolvam uma classe personalizada (ou CSS personalizado) em torno de qualquer bloco, incluindo outros contêineres.

Não há razão para adicionar limitações de aninhamento a um bloco de contêiner genérico.

Eu entendo o valor dos elementos HTML semânticos, mas também me pergunto se há uma maneira de delegar essa funcionalidade aos plug-ins de alguma forma, de forma que esteja disponível como uma opção para usuários avançados, mas os usuários médios não precisam se preocupar com isso. Porque no minuto em que você adiciona isso, você não apenas assume a responsabilidade por fornecer a funcionalidade, mas também a responsabilidade de educar os usuários sobre as implicações semânticas ... que geralmente são altamente situacionais.

@chriskmnds Bom ponto. Acho que este é o lugar errado para definir tags de contêiner.

O bloco de contêiner deve funcionar como um contêiner genérico sem significado semântico.

O significado semântico deve ser fornecido pela funcionalidade de modelo de bloco (futuro), de modo que o conteúdo <aside> possa ser uma parte de um modelo e <section> outro.

Dessa forma, os usuários podem organizar o conteúdo em containers da maneira que desejarem (em qualquer nível de profundidade), sem afetar o significado semântico.

Concordo que ser capaz de trocar o elemento HTML parece um pouco avançado para a maioria das pessoas e provavelmente não pertence a uma configuração básica de Gutenberg.

O significado semântico deve ser fornecido pela funcionalidade de modelo de bloco (futuro), de modo que o conteúdo <aside> possa ser uma parte de um modelo e <section> outro.

Isso seria definitivamente bom para explorar.

Eu não discordo dos pontos feitos para manter a UX base simples, mas eu perguntaria onde você adicionaria <section> , <nav> , <header> , etc. elementos de envolvimento? Um bloco de contêiner genérico, que é essencialmente um elemento de invólucro, parece uma escolha natural. Isso pode ser preferido do que um bloco duplicado para cada um desses casos. O padrão pode ser <div> e o usuário nunca precisa tocar na configuração, a menos que seja necessário.

E se as opções para elementos HTML funcionassem de maneira semelhante às configurações de alignwide / full, onde uma matriz de elementos com suporte pode ser definida a partir do tema ou plugin?

@jvisick Idealmente, esses elementos de

Usando um modelo de layout de bloco, você pode configurar vários blocos de contêiner padrão e fornecer uma configuração (no código) para qual deve ser o nome da tag gerada pelo bloco de contêiner.

@rchipka Vejo de onde você está usando modelos de layout que fornecem aos usuários áreas predefinidas para gerenciar o conteúdo. Estou olhando para isso mais de uma perspectiva de usar Gutenberg como um construtor de páginas para páginas que não estão definidas e nas quais ser capaz de definir que tipo de elemento HTML é usado no editor seria útil. Acho que os dois cenários são importantes.

Dito isso, concordo com @melchoyce que definir elementos HTML não é necessário para uma execução inicial do bloco de contêiner, mas acho que é algo que vale a pena explorar na próxima fase de 'construtor de página'.

As seções são essencialmente de 1 coluna ... bem, colunas.

Estou percebendo que o bloco 3.0.0 Columns (beta) não permite 1 coluna em seu controle deslizante.

Não tenho certeza se seria melhor ficar com apenas o bloco de colunas ao redor e combinar essas implementações. Qual é a desvantagem?

Uma coisa que seria bom adicionar é alternar se o contêiner (seção) deve ser de largura total ou contido. Se estiver contido, deve respeitar o content_width definido no tema (# 5650), caso contrário, deve ter largura total. Acho que a maioria dos criadores de páginas por aí tem esse recurso.

Sim, isso está incluído na barra de ferramentas rápida em meu último modelo.

@melchoyce Lembre-se de que haverá situações em que o bloco de seção / contêiner deve ter largura total, mas o conteúdo dentro do bloco de seção / contêiner não. Como isso seria tratado?

Achei que, por padrão, o próprio contêiner poderia ter largura total, mas qualquer conteúdo dentro dele que não suporte nativamente largura total (como imagens / blocos de capa) ainda seria restrito à largura do editor.

@melchoyce Supondo que entendi corretamente, isso significa que os controles de largura no bloco do contêiner afetariam apenas o fundo do contêiner e nunca o conteúdo? Isso faz sentido. Obrigado por esclarecer. : +1:

Sim, é isso que estou pensando!

Não tenho certeza se foi discutido, mas uma seção pode ser um elemento HTML "seção" e também um "artigo", "div" ou qualquer outra coisa, certo? Seria bom tê-lo como selecionável
Isso também pode tornar o bloco de "linha" desnecessário, eu acho

Implementado em um plugin

var el = wp.element.createElement,
    registerBlockType = wp.blocks.registerBlockType,
    InnerBlocks = wp.editor.InnerBlocks;

registerBlockType( 'nbrummerstedt/section', {
    title: 'Section',
    icon: 'universal-access-alt',
    category: 'layout',
    attributes: {},
    edit: function( props ) {   
        return el( 'section', {className: props.className},
            el( InnerBlocks )
        );
    },
    save: function( props ) {
        return el( 'section', {className: props.className }, 
            el( InnerBlocks.Content )
        );
    }
} );

@eddr Isso foi discutido: https://github.com/WordPress/gutenberg/issues/4900#issuecomment -392925877

Ainda acho que uma lista suspensa para selecionar a tag HTML usada é uma boa ideia. Parece a maneira mais fácil de integrar elementos HTML semânticos como <aside> e <section> sem criar um monte de blocos muito semelhantes.

@nbrummerstedt Boa implementação básica inicial, mas o bloco agora é <div> como elemento, embora idealmente (como mencionado acima e nos comentários anteriores), você seja capaz de alterar o HTML elemento usado de <div> a <section> , <aside> e talvez até <article> .

Aqui está uma versão revisada de sua implementação:

( ( blocks, editor, element ) => {
    const el = element.createElement,
        { registerBlockType } = blocks,
        { InnerBlocks } = editor;

    registerBlockType( 'nbrummerstedt/container', {
        title: 'Container',
        icon: 'universal-access-alt',
        category: 'layout',
        attributes: {},
        edit: ( props ) => {    
            return el( 'div', {className: props.className},
                el( InnerBlocks )
            );
        },
        save: ( props ) => {
            return el( 'div', {className: props.className }, 
                el( InnerBlocks.Content )
            );
        }
    } );
} )( window.wp.blocks, window.wp.editor, window.wp.element );

Por que isso foi removido do marco do WordPress 5.0, @mtias? Isso parece algo que provavelmente deveria estar na versão inicial, simplesmente por ser útil e simples. Muitos blocos não têm configurações de fundo porque foi assumido que você usaria o bloco Container para isso. Não é nem tão difícil implementar esse bloqueio, não é? Não vejo por que isso deveria ser adiado para uma versão pós-WordPress 5.0.

Em outra nota, recentemente eu estava testando o Oxygen e fiquei impressionado com seu sistema de layout baseado em flexbox. E se o bloco de contêiner implementasse alguns desses recursos? Aposto que poderia ser muito poderoso e fornecer uma forma alternativa de ter layouts diferentes do bloco de colunas ... talvez pudesse até tornar o bloco de colunas desnecessário?

https://oxygenbuilder.com/documentation/visual-editing/layout-spacing/
https://oxygenbuilder.com/documentation/visual-editing/responsive-controls/

Eu recomendo fortemente verificar isso. Na verdade, eu recomendo apenas dar uma boa olhada em Oxygen inteiramente. É muito diferente de todos os outros plug-ins do construtor de páginas e acho que há muitas boas ideias que Gutenberg poderia usar.

Eu definitivamente concordo, isso deve estar na versão 5.0, você precisa de um contêiner para evitar qualquer solução hacky usando o bloco de colunas.

Eu também acho que esse bloco deve estar disponível em breve. Muitas agências de desenvolvimento do WordPress estão esperando por este bloco antes de construir com Gutenberg.

@ dingo-d e @ericvalois Sim, fosse postagens de blog precisamente por causa da falta de três coisas: colunas responsivas, colunas de largura diferente e um bloco de contêiner.

Para elaborar o que disse anteriormente sobre o bloco Container adotar coisas que o Oxygen faz, acho que o bloco Container poderia ter uma opção para alterar a direção do fluxo de seus blocos aninhados da vertical padrão para a horizontal. Também pode haver opções de alinhamento vertical e horizontal como as do Oxygen. Isso seria realmente poderoso - especialmente se combinado com a capacidade de alterar essas opções responsivamente como a maioria dos plug-ins de construtor de página permite.

Obviamente, há o problema notável de que um bloco Container usando alinhamento / layout baseado em Flexbox não permitiria que blocos alinhados com float fossem aninhados diretamente nele. Mas acho que há uma solução simples para isso: adicionar a capacidade de fazer um Container usar o layout CSS display: block padrão ou o layout Flexbox. O modo display: block padrão seria o padrão, já que é o que o documento raiz usaria. Habilitar o modo de exibição flexbox faria com que todas as opções de alinhamento simples apareçam no inspetor. Além disso, você obviamente gostaria de dar aos 2 modos de layout um nome diferente no inspetor para torná-lo mais amigável. Não tenho certeza de como você os chamaria, no entanto. Talvez “Padrão” e “Flexível”?

Permitir que os blocos de contêiner usem o modo que suporta flutuações ou o modo com as melhores opções de alinhamento / layout seria muito útil. Você pode aninhar blocos de contêiner para usar os dois tipos de layout, quando necessário. Adicione isso às outras habilidades que o bloco de contêiner poderia ter (opções de plano de fundo, capacidade de escolher a tag HTML para adicionar significado semântico sem ter que recorrer a blocos de HTML personalizados, etc.) e o bloco de contêiner acabaria sendo um dos mais importantes e blocos úteis no núcleo do WordPress.

Notavelmente, se o bloco Container com dois modos de layout soar como muitos recursos (e eu realmente não acho que seria um problema), então poderia haver apenas dois blocos separados:

• um bloco de contêiner padrão que suporta flutuadores, mas não tem todas as opções avançadas de alinhamento / layout
• um bloco de contêiner avançado (ou layout avançado ou layout flexível ou como quiser) que usa o layout Flexbox e fornece todas as opções legais

Eu recomendo conferir este vídeo de documentação do Oxygen para ver como seu sistema de layout funciona. É realmente impressionante:

https://www.youtube.com/watch?v=NnSfR-YFcQI

Acho que há muito potencial aqui para tornar Gutenberg muito poderoso . Obviamente, para uma implementação inicial, eu esperaria apenas que o bloco Container tivesse opções de plano de fundo, a capacidade de alterar o elemento HTML usado e a opção de fazer com que o Container fosse de largura total (mas não o conteúdo dentro dele). Talvez apenas as opções de plano de fundo.

Na verdade, apenas ter um bloco Container que não tem nenhuma opção ainda é útil, porque torna mais fácil estilizar um grupo de blocos via CSS.

É importante pensar em Gutenberg não apenas como parar após o 5.0. Este é um bloco muito útil e será explorado, mas para a fase um, focar na edição não é realmente necessário. Quando o projeto se expande além da simples edição no layout, não há dúvida de que uma solução é necessária. Ninguém está dizendo que isso não será criado, é uma questão de priorizar o que é editor e o que passa para a fase dois.

Mas a questão é que a maioria das pessoas está usando o Gutenberg para fins de layout, não para escrever postagens.

As pessoas estão acostumadas a escrever posts como um documento do Word, então eles estão desativando o Gutenberg nas páginas Post.

Mas a questão é que a maioria das pessoas está usando o Gutenberg para fins de layout, não para escrever postagens.

Em qual fonte de dados você está baseando essa suposição?

Conversei com várias pessoas durante a WCEU em Belgrado, todas concordam que acham estranho escrever posts com Gutenberg e, portanto, estão desativando-o em Posts.

Ao contrário do que @ dingo-d viu, eu só uso o Gutenberg para postagens. Na verdade, acho a experiência de pós-produção muito mais agradável em Gutenberg do que no Editor Clássico. Em parte por causa da natureza mais modular e dos controles contextuais, e em parte porque não há mais tags <p> invisíveis irritantes inseridas em todos os lugares. Isso sempre me incomodou.

Eu preciso de um bloco de contêiner (mesmo sem opções) e um bloco de colunas decente (ou algum outro bloco de layout) para usar o Gutenberg para a construção de página uniforme. Parece que o bloco de colunas receberá algum tipo de resposta básica (consulte # 6048), o que significa que é apenas a falta de um bloco de contêiner que está me impedindo de usar o Gutenberg em mais contextos.

Eu sei que o bloco Container obviamente será adicionado em algum momento (provavelmente não depois do WordPress 5.1), mas acredito fortemente que ele deve ser adicionado antes do WordPress 5.0 sair. Mesmo no contexto de escrever posts, um Container pode ser útil para algo como <aside> (se ele tivesse o recurso suspenso de seleção de elemento HTML) para semântica adicionada. Neste momento, se você quiser envolver qualquer coisa em outro elemento HTML para adicionar semântica, você deve usar o bloco HTML personalizado, o que significa que você não pode aproveitar os recursos do bloco de parágrafo para quaisquer parágrafos nesse bloco HTML personalizado, ou quaisquer recursos do bloco de imagem para quaisquer imagens nesse bloco de HTML personalizado e etc.

@karmatosed

Ninguém está dizendo que isso não será criado, é uma questão de priorizar o que é editor e o que passa para a fase dois.

Na minha opinião, o bloco Container é absolutamente algo que pertence à primeira fase.

O que eu acho meio estranho é que o bloco de colunas parece que vai chegar ao WordPress 5.0 (possivelmente ainda com o rótulo “(Beta)”, mas o bloco de contêiner pode não? Se o foco agora deveria estar na escrita postagens, então por que um bloco de colunas foi adicionado, mas nenhum bloco de contêiner? O bloco de contêiner, na minha opinião, é muito mais útil no contexto de postagens do que o bloco de colunas. E, claro, ele também tem muitos benefícios no contexto da construção da página também.

Se o bloco Container não chegar ao WordPress 5.0, isso significa que ele não será lançado até o 5.1, o que o atrasa por meses para ser usado pela maioria das pessoas. Quero que Gutenberg seja bem-sucedido e acho que não há razão para reter o lançamento de algo básico como um bloco de contêiner até o WordPress 5.1. Para uma boa primeira impressão, eu até recomendaria que ele fosse adicionado antes do texto explicativo do WordPress 4.9.8.

Não espero que tenha todos os recursos que as pessoas sugeriram; sua mera existência é suficiente para resolver muitos casos de uso comuns que atualmente não são cobertos, exceto por uma solução bastante hacky de usar um bloco de colunas com o controle deslizante de colunas manualmente definido como 1. E então, ter apenas uma opção como opções de cor de fundo tornaria muito mais útil.

Eu concordo que é um bloco legal e útil, mas sempre foi mais sobre a fase 2 do projeto e realmente precisamos nos concentrar ou nunca iremos lançar. Construímos a infraestrutura de blocos aninhados porque era importante obter as abstrações certas e permitir que as pessoas construíssem seus blocos de layout personalizados, de forma que um bloco de núcleo real como esse fosse menos crítico. O foco está em obter a IU aninhada e filha correta em geral (usando _Columns_ como a cobaia).

Este problema também está em aberto há cinco meses e não houve nenhuma proposta de implementação sólida que inclua coisas como cores, larguras, direção dos blocos vs colunas de aninhamento, sobreposição com imagem da capa, etc. Da maneira que está, podemos não priorize isso sobre outro trabalho de propósito geral que precisamos fazer, e o aviso de "teste" iminente no WordPress. Isso não significa que ele não vai passar pelo corte, especialmente se alguém quiser colocar sugestões em código.

Além disso, o maior problema para mim é que não está claro - visível apenas na conversa aqui - qual deve ser a experiência do usuário ideal para se comprometer com uma implementação. Coisas como expor tags html parecem abertamente complexas e não intuitivas para um usuário regular. A própria noção de um contêiner é algo que precisa de testes mais amplos para ver se é a melhor abstração de layout, o que, novamente, deveria ser algo a ser descoberto na próxima fase de foco. Existem também algumas incógnitas em como tal bloco poderia cascatear estilos em blocos arbitrários dentro - é relativamente simples considerar os blocos principais, mas não qualquer bloco arbitrário.

Ao mesmo tempo, um desenvolvedor que deseja oferecer um bloco personalizado deve ter facilidade para colocá-lo junto (como o snippet mostrado acima) com qualquer tag que desejar usando InnerBlocks e coletar o feedback do usuário. Portanto, há menos pressão sobre o núcleo tendo esse bloqueio (e tendo que mantê-lo). Dito isso, qualquer pessoa deve se sentir à vontade para fazer uma sugestão via RP e ajudar no teste do usuário. Eu ficaria bem em adicioná-lo ao plugin como "experimental" com a noção de que ele pode ser retirado para o 5.0.

@SuperGeniusZeb Oxygen é muito legal! Definitivamente, deve ser analisado por algumas dessas explorações.

Por curiosidade, o que acontece se temas e plug-ins adicionarem seus próprios blocos de seção e o usuário desativar o plug-in ou alterar os temas? Existe algum tipo de fallback no lugar? Ou o usuário perde seu conteúdo?

@tomusborne Há um problema com esse tipo de situação: # 7811.

Ah! Eu não sabia que isso era discutido aqui. Então eu também fiz um plugin conforme precisava.

https://github.com/marcusig/gutenberg-section-block

Estive observando este tópico e aprecio todo o pensamento nele. Recentemente, lancei um bloco de contêiner no plug-in Atomic Blocks que tem margens, preenchimentos, largura do contêiner e opções de imagem e cor de fundo. Espero que isso seja útil e possa nos segurar até que um bloco principal chegue em uma data posterior!

Seguindo essa questão .. Criei um bloco "Container" que permite escolher a estrutura das colunas, entre outras opções.
Se isso puder ajudar a melhorar o bloco "Colunas" ou criar um novo no núcleo, está aqui: https://github.com/MarieComet/WP-container-block/

@MarieComet Isso é legal, mas acho que seu bloco deve ser dividido em 2 blocos diferentes. O primeiro deve ser um bloco de colunas com todas as opções de layout da estrutura baseada em colunas. O segundo seria um bloco Container que tem opções de plano de fundo e opções de layout que não são baseadas em colunas, como a capacidade de usar flex para fazer o layout dos filhos horizontalmente em vez de verticalmente e alinhá-los e justificá-los usando opções que correspondem às propriedades CSS Flex.

Você provavelmente também pode usar o bloco Container para substituir os blocos de Coluna individuais, embora possa haver algumas opções que você gostaria de ter em uma Coluna que não fazem sentido em uma Seção.

Eu percebi que o futuro de fazer layouts com HTML e CSS não é sempre usar colunas como a maioria dos construtores de páginas, mas também usar CSS Flex e Grid para exibir conteúdo usando menos <div> s em a marcação e têm um estilo mais flexível e limpo. Estou principalmente inspirado pelo que o Oxygen está fazendo. Falei sobre o oxigênio neste comentário .

Este problema não é substituir o bloco de colunas agora. É importante manter o foco no assunto, um bloco de seções.

@karmatosed @melchoyce Falando nisso, esse número não deveria ser renomeado? Paramos de chamá-lo de "Seção" e mudamos para "Recipiente" para evitar confusão com elementos <section> .

O nome ainda não foi decidido, então estamos todos bem saindo como está por um tempo.

No momento, estou tentando implementar um tema junto com o editor de Gutenberg.

O layout do site possui diferentes áreas com diferentes fundos, que contêm diversos itens como parágrafos ou listas. Isso é para fins de layout e para fins de navegação. Os blocos de seção / contêiner devem funcionar como âncoras / devem ter IDs CSS exclusivos.

Não posso terminar este tema sem "invadir Gutenberg" criando os próprios blocos. Isso poderia ser feito com este como bloco principal. Eu não usaria o editor de Gutenberg apenas para texto simples e layouts simples - meu layout / design futuro deve ser feito junto com o tema e o sistema de blocos de Gutenberg.

Eu realmente espero que este tópico receba uma prioridade maior.

Estou usando blocos de contêiner de terceiros em todos os lugares (por exemplo, blocos atômicos), em combinação com o bloco de colunas. Eles têm sido super úteis e meu bloqueio mais popular. Acho estranho que seja considerado mais tarde no futuro ou como um add-on; precisa estar no núcleo.

Caso contrário, eu apenas construiria manualmente os contêineres na visualização HTML, no entanto, isso é irritante / ineficiente porque a visualização HTML está a um clique de menu extra de distância. Há um atalho de teclado para a visualização HTML ... shift + option + cmd + M ... yeesh. E nem mesmo alterna para frente e para trás. Acertar o atalho novamente não faz nada. Para voltar à visualização WYSIWYG, você precisa percorrer os menus. Uma chave seletora grande e robusta na barra de ferramentas principal seria excelente.

Alguém catalogou / está mantendo uma lista de implementação atualmente em uso? Eu acho que também precisaria de algum tipo de matriz de parâmetro de "coisas feitas certo e errado". Por exemplo, especificar unidades codificadas (px) para preenchimentos / margens associados (incorreto), quando as unidades provavelmente devem ser uma escolha deixada para o usuário (direita), etc.

https://editorblockswp.com/library/ tem alguns no catálogo, mas para empurrar esse problema para a frente, parece que algo específico para Seções / Containers precisa acontecer.

Na minha opinião, um bloco de contêiner básico teria pelo menos as seguintes opções:

• imagem de fundo
• cor de fundo
• capacidade de sobrepor a cor de fundo na imagem e controlar a opacidade
• opções de preenchimento e margem para todas as 4 direções, com a capacidade de alternar as unidades usadas individualmente para cada valor
• suporte para alinhamentos de flutuação à esquerda, flutuação à direita, ampla e completa
• capacidade de controlar a largura máxima dos blocos contidos de alguma forma
• capacidade de escolher o elemento html usado pelo contêiner

Além disso, eu preferiria também o seguinte:

• Opções de layout flexível CSS: capacidade de definir a direção do fluxo de conteúdo de cima para baixo para esquerda-direita, direita-esquerda e base-topo; e capacidade de definir o alinhamento vertical e horizontal do conteúdo
• é claro, usar opções flex é incompatível com alinhamentos flutuantes, então o bloco teria que ter pelo menos 2 modos de layout: padrão e flex, ou então teria que haver um bloco Flex Container separado
• tamanho da fonte e opções de cor para definir os padrões para o conteúdo no contêiner e evitar ter que defini-lo para cada bloco contido individualmente

Felix Arntz acaba de publicar uma postagem no blog sobre a implementação de seu bloco de seção.
eu gosto da imagem de fundo responsiva.
https://felix-arntz.me/blog/building-a-reusable-gutenberg-section-block/

Nas últimas semanas tenho experimentado a implementação de Marc Lacroix, que funciona bem, mas parece quebrar no gutenberg 3.9.0 https://github.com/marcusig/gutenberg-section-block

Eu estive pensando sobre este há algum tempo. O fato de tantas implementações terem surgido para ele significa que é bastante valioso e provavelmente é melhor para o núcleo oferecer um mecanismo consistente para evitar a fragmentação. Minha principal preocupação é a complexidade de um bloco de "seção" para um usuário.

Proponho começar muito simples, com apenas um container (uma única área InnerBlocks), alinhamentos amplos e completos, e uma configuração para a cor de fundo (sem imagem, etc - temos "Capa" para isso).

Não temos muito tempo para fazer isso se quisermos no 5.0.

@mtias Se expor um bloco Container para o usuário final for uma preocupação, então talvez cada bloco deva ter apenas um Container ou Configurações de Container por padrão.

Então, não precisamos nos preocupar em ensinar ao usuário final que ele precisa embrulhar algo em um contêiner para que tenha certas coisas, como uma imagem de fundo.

Eu acho que isso é realmente uma boa ideia porque então as pessoas que desejam estender ou agrupar blocos arbitrários terão um lugar claro para fazer isso, e os usuários finais estarão familiarizados com isso porque está em cada bloco.

Talvez "Configurações do contêiner" possa ser uma guia ao lado de "Configurações de bloqueio". Este seria um lugar (extensível) para os desenvolvedores inserirem (ou filtrarem) coisas como configurações de imagem de fundo, configurações de largura, etc.

Isso também daria aos desenvolvedores um lugar para colocar configurações mais complexas que podem ser aplicadas a praticamente qualquer bloco, como controles responsivos / de ponto de interrupção.

@rchipka Tecnicamente, a maioria dos blocos são

O poder de um contêiner não está exatamente em um único bloco, mas permite que você adicione outros blocos dentro do contêiner, criando layouts, seções e estrutura de página mais complexos.

@mikemcalister Bom ponto, o usuário final ainda precisaria de uma maneira de agrupar / organizar visualmente a árvore de blocos.

Eu acho que a filosofia permanece a mesma. Se o editor tivesse um mecanismo de agrupamento de blocos no estilo árvore (ou seja, sem uma interface de "Bloco de contêiner"), então as "Configurações do contêiner" para qualquer bloco filho refletiria as configurações desse grupo (ou seja, aquele nível na árvore).

Novamente, o único ponto dessa ideia é reduzir o número de etapas envolvidas para o usuário final e, portanto, também reduzir a curva de aprendizado e aumentar a descoberta.

Acho que o principal problema é que atualmente Gutenberg está muito limitado ao conteúdo padrão de postagem / página. Sem um bloco de seção / contêiner, não temos como permitir que os usuários criem páginas iniciais com seções de largura total (com fundo de cor sólida / gradiente ou imagem de fundo de largura total) com todos os tipos de conteúdo dentro (esperançosamente por meio de blocos aninhados).

Um bloco de seção / contêiner seria perfeito aqui. Mesmo um básico que poderia ser estendido com mais controles por temas / plug-ins. Eu adoraria obter mais configurações de alinhamento lá também. Já estamos fazendo algo com o CMB para ter um criador de pseudo-página direto nas páginas, mas realmente espero que Gutenberg possa tornar tudo isso mais flexível para todos.

@JiveDig Não acho que ninguém, incluindo a equipe de Gutenberg, se oponha a algum tipo de mecanismo de contêiner de bloco.

A principal hesitação da equipe de Gutenberg (neste caso e em muitos outros) é manter a interface central em um nível de complexidade Squarespace do ponto de vista de UI / UX.

Para que isso seja implementado no núcleo, parece que o principal problema é encontrar uma maneira de representá-lo sem sobrecarregar os usuários finais.

Embora, na minha opinião, isso não parece ser um grande negócio, um "Block Container" não colocar uma pequena carga sobre o usuário final, exigindo conhecimento de seu propósito e seu uso.

É por isso que propus o conceito de "agrupamento" como uma analogia mais acessível a "contêineres" para usuários finais.

O usuário final não pensaria em termos de embrulhar blocos em contêineres e, em vez disso, pensaria em termos de agrupar blocos, o que parece mais intuitivo.

Dessa forma, o usuário final não precisa saber de nada com antecedência para agrupar blocos e aplicar configurações a esse grupo.

Claro, esses "grupos" funcionariam exatamente como um bloco Container internamente, é apenas uma interface de front-end mais integrada e intuitiva.

@rchipka Uma maneira muito fácil de abordar isso seria a capacidade de selecionar um ou mais blocos e clicar na opção "Mover bloco (s) selecionado (s) para o bloco Container" no menu "mais". Desta forma, os blocos não precisam de um painel de configurações _adicional_.

Sim, um bloco de seção deve estar no núcleo. Renderizar uma div simples no HTML é suficiente. Mas, uma vez que existem literalmente centenas de atributos que podem ser oferecidos, sugiro fortemente que os dois atributos que devem ser oferecidos sejam CLASSE e ID (sendo ID o menos crítico). Dessa forma, os elementos podem ser estilizados em CSS onde deveriam estar.

-
Modos Wes
Uma história secreta do povo americano do rio
http://peoplesriverhistory.us

Enviado da minha Apple] [e

Em 12 de outubro de 2018, às 8h09, Matias Ventura [email protected] escreveu:

Eu estive pensando sobre este há algum tempo. O fato de tantas implementações terem surgido para ele significa que é bastante valioso e provavelmente é melhor para o núcleo oferecer um mecanismo consistente para evitar a fragmentação. Minha principal preocupação é a complexidade de um bloco de "seção" para um usuário.

Proponho começar bem simples, com apenas um container e uma configuração para a cor de fundo (sem imagem, etc - temos "Capa" para isso).

Não temos muito tempo para fazer isso se quisermos no 5.0.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

Novamente, cada bloco deve ter a capacidade de definir seu atributo de classe. Independentemente do tipo.

-
Modos Wes
Uma história secreta do povo americano do rio
http://peoplesriverhistory.us

Enviado da minha Apple] [e

Em 12 de outubro de 2018, às 8h40, Robbie Chipka [email protected] escreveu:

@mtias Se expor um bloco Container para o usuário final for uma preocupação, então talvez cada bloco deva ter apenas um Container ou Configurações de Container por padrão.

Então, não precisamos nos preocupar em ensinar ao usuário final que ele precisa embrulhar algo em um contêiner para que tenha certas coisas, como uma imagem de fundo.

Eu acho que isso é realmente uma boa ideia porque então as pessoas que desejam estender ou agrupar blocos arbitrários terão um lugar claro para fazer isso, e os usuários finais estarão familiarizados com isso porque está em cada bloco.

Talvez "Configurações do contêiner" possa ser uma guia ao lado de "Configurações de bloqueio". Este seria um lugar (extensível) para os desenvolvedores inserirem (ou filtrarem) coisas como configurações de imagem de fundo, configurações de largura, etc.

Isso também daria aos desenvolvedores um lugar para colocar configurações mais complexas que podem ser aplicadas a praticamente qualquer bloco, como controles responsivos / de ponto de interrupção.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

Não me oponho ao método de agrupamento (contanto que eu pudesse atribuir atributos de classe), embora seria ótimo se TAMBÉM houvesse um bloco de contêiner se você quisesse construir dessa forma.

-
Modos Wes
Uma história secreta do povo americano do rio
http://peoplesriverhistory.us

Enviado da minha Apple] [e

Em 12 de outubro de 2018, às 10h50, Chris Van Patten [email protected] escreveu:

@rchipka Uma maneira muito fácil de abordar isso seria a capacidade de selecionar um ou mais blocos e clicar na opção "Mover bloco (s) selecionado (s) para o bloco Container" no menu "mais". Desta forma, os blocos não precisam de um painel de configurações adicional.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

@chrisvanpatten Eu concordo, entretanto esta solução não aborda adequadamente a preocupação original de @mtias de expor o conceito de um Contêiner ou Seção para o usuário final.

A questão, conforme levantada por @mtias , não é sobre a logística de colocar blocos em um contêiner, mas sim apresentar intuitivamente essa interface ao usuário final (sem expor tipos de bloco adicionais).

A discussão "como colocamos os blocos em um contêiner" é necessária. No entanto, não acho necessariamente que seja muito complexo para o usuário. Muitos usuários não o usarão, ou pelo menos não o usarão fora de sua página inicial. Muitos de nossos clientes e clientes de tema expressam seus desejos / necessidades de sites em termos visuais adequados para um bloco de seção. Eles dizem coisas como, "Eu quero uma grande largura total {barra / área / seção / bloco / painel / extensão} com uma imagem bonita" seguida por "e {inserir solicitações de conteúdo aqui} nessa seção". Eles entendem visualmente que a seção em si (o contêiner) é separada do conteúdo dentro dela.

Concedido, como fazer isso por meio da IU precisa ser resolvido, mas espero que meu ponto acima faça sentido.

@chrisvanpatten Minha declaração anterior é baseada exclusivamente na semântica dos tipos de bloco.

A única razão pela qual estou discutindo semântica aqui é em nome de @mtias , já que houve um problema levantado com a complexidade de expor essa semântica em primeiro lugar.

Gosto da sua sugestão, mas se estou a seguir a minha analogia, talvez altere a semântica "Agrupar bloco (s) seleccionado (s)".

@rchipka não foi assim que interpretei seu comentário - entendi que o bloco proposto precisaria ser simples, mas ainda precisaria ser um bloco (se for uma área InnerBlocks, que deve ser incluído um bloco). Talvez haja uma maneira de ocultá-lo do insersor e criar apenas blocos de contêiner selecionando vários blocos e fornecendo uma opção “colocar no contêiner”, mas com base no meu entendimento do sistema, isso ainda significaria um bloco dedicado.

Dito isso, estou mais do que feliz por estar errado :)

@JiveDig Concordo plenamente ....

No entanto, a equipe de Gutenberg parece ser altamente sensível à exposição dessas coisas ao usuário final no núcleo de Gutenberg.

Esta é minha única base para levantar esses argumentos e apresentar essas idéias.

Novamente, se fosse eu, teríamos apenas o maldito bloco de contêiner.

Não acho que um bloco de contêiner realmente faça sentido, já que bagunçaria a IU. Eu prefiro ver algo como o marcador "Quebra de seção" que você vê embutido no Microsoft Word. Adicionar uma quebra de seção ofereceria algumas opções de estilo no inspetor, como um nome de classe para a seção, cor de fundo, cor do texto, sombra projetada, o que quer que defina estilisticamente sua seção. Ele pode ser inserido como qualquer bloco e movido como qualquer bloco.

@rwrobe Essa ideia não funciona para containers aninhados.

No momento, estou construindo um site com Gutenberg e usei intensamente uma versão modificada do bloco de seção de

• "Seção" é o melhor nome para o bloco. Seu significado é claro para desenvolvedores e usuários finais, e evita complicar a marcação / opções usando logicamente o bloco <seção>.

• As únicas opções de menu de contexto necessárias são alignnormal / wide / full (e na verdade eu só uso alignfull). O alinhamento não afeta os blocos internos, que permanecem dentro do alinhamento normal, a menos que tenham suas próprias opções de alinhamento. O principal caso de uso tem sido a criação de uma cor de fundo de alinhamento completo que contém um bloco de texto alinhado normal - um padrão de design muito comum que não é possível atualmente.

• As únicas configurações de bloco da barra lateral necessárias são Cor de fundo e Imagem de fundo (com opções de opacidade / fixas associadas). Qualquer personalização adicional pode ser tratada com a classe CSS personalizada. (Incluir a opção Imagem de fundo também tem o efeito colateral de transformar isso em uma versão muito mais útil do bloco de cobertura.) (Mas: se @mtias estiver certo, evitar essa conversa apenas incluindo a opção Cor de fundo eliminaria isso porta mais rápido, então eu sou totalmente a favor.)

• A usabilidade é simples. Mais fácil do que colunas, que já existem há algum tempo. O único problema potencial é que, quando a seção é adicionada pela primeira vez, o foco muda para um parágrafo dentro da seção, portanto, pode ser difícil dizer que a seção foi apenas adicionada até que você passe o mouse sobre ela. Uma solução possível para isso é usar como padrão uma cor de fundo cinza claro.

@ZebulanStanphill Você está falando sobre colunas? Pude ver os blocos de "seção" fazendo o trabalho para conteúdo separado verticalmente - poderia até mesmo haver uma alternância para estilos herdados da seção anterior, que meio que permite que você "aninhe" variações de estilo dentro de uma seção.

A composição horizontal, como nas colunas, parece necessariamente mais difícil devido à maneira como Gutenberg constrói a página de cima para baixo em blocos de largura total.

@mikedance Eu acho que é exatamente o que é necessário. Uma opção de imagem de fundo seria importante embora IMO. Talvez esse bloco possa substituir o Bloco de capa, embora a nomenclatura possa não ser adequada para pessoas que _só_ desejam uma imagem de fundo com texto básico sobre ela. Embora haja alguma sobreposição na funcionalidade, isso tiraria uma grande porcentagem de casos de uso para o bloco de Seção sem adicionar suporte à imagem bg.

@rwrobe Deve-se notar que você pode ter blocos dispostos horizontalmente. Os blocos da coluna (observe a falta de "s") são apenas isso. O bloco de colunas os posiciona horizontalmente. A IU provavelmente poderia ser melhorada em algumas áreas, mas os blocos não se limitam a ter largura total ou disposição vertical.

@mikedance

"Seção" é o melhor nome para o bloco. Seu significado é claro para desenvolvedores e usuários finais, e evita complicar a marcação / opções usando logicamente o

quadra.

Porque o elemento <section> tem semântica anexada a ele, seria melhor se você pudesse escolher usar um <div> vez de um <section> , já que em muitos casos você deseja embrulhar vários blocos, mas eles não são semanticamente parte de uma seção. Na verdade, seria ainda melhor se você também pudesse escolher usar elementos como <aside> ou <header> , o último sendo particularmente útil para adicionar semântica a títulos com fundos na construção de páginas.

Por outro lado, acho que ter opções de imagem de fundo disponíveis para um bloco de contêiner seria bastante útil. Claro, a sobreposição com o conceito de bloco de cobertura torna-se bastante aparente. Se você tornar o bloco de cobertura mais flexível, ele basicamente se tornará um bloco de contêiner de qualquer maneira, então talvez o conceito de bloco de cobertura não precise existir? Um bloco Container pode fazer praticamente tudo o que faz. O conceito de capa pode ser apenas um modelo de bloco reutilizável.

@ZebulanStanphill , concordo. Que uma configuração avançada que permite que você selecione se é uma seção, cabeçalho, lado ou div (padrão) seria útil. Sim, a maioria dos usuários pode não usar essa opção, mas é uma opção que oferece suporte para um bom desenvolvimento da web.

Como um tema pode ser integrado? Um tema pode adicionar "variações" a um bloco, neste caso
o bloco de seção e o usuário pode escolher diretamente um de um ilst e ver os estilos resultantes aplicados?
Também pode ser muito útil adicionar um filtro ou gancho ao bloco de seção para permitir
um tema adiciona wrapper e outros elementos que às vezes são necessários para estilização.

@ZebulanStanphill @wmodes Eu duvido que incluir uma opção para selecionar o elemento

@mikedance Concordo, provavelmente devemos usar apenas <div> . Se o layout semântico for uma preocupação, ele seria mais bem tratado como uma extensão do bloco de contêiner.

Os temas

@mikedance

De um certo ponto de vista, o

elemento é tão semântico quanto possível, porque o usuário já o está definindo como uma "Seção" em virtude da criação do bloco.

Acho que entendi o que você está dizendo, mas discordo. Em muitos casos, um bloco Container seria usado simplesmente para adicionar uma cor de fundo a um par ou mesmo apenas a um bloco que não tem suas próprias opções de fundo (ou outro estilo). Um bloco de lista embrulhado em um recipiente para dar a ele uma cor de fundo e destacá-lo não significa que a lista está em sua própria seção.

Mas sim, <div> é a escolha mais neutra, pois não tem significado semântico. Se nunca haverá uma opção no núcleo para alterar o elemento HTML, então <div> é a melhor escolha.

O principal motivo pelo qual desejo a capacidade de escolher a tag HTML é porque ela permite que você crie páginas e postagens semânticas com mais facilidade, sem ter que recorrer ao bloco HTML personalizado ou plug-ins que adicionam blocos personalizados. Se você deseja usar uma tag <section> no Gutenberg agora, você acaba tendo que colocar tudo nessa seção em um bloco de HTML personalizado, perdendo os recursos de edição visual para itens como parágrafos, listas, etc. teria de outra forma. Talvez o alternador de tag pudesse ser mostrado no grupo Avançado no inspetor?

@strarsis @ZebulanStanphill

Você pode encontrar documentos para adicionar Block Styles no manual em extensibilidade https://wordpress.org/gutenberg/handbook/extensibility/extending-blocks/#block -style-transactions

@ajitbohra Obrigado! Verifiquei aquela página várias vezes, mas continuei perdendo aquela seção de alguma forma. :rindo:

@ajitbohra : Obrigado! Existe uma demonstração para variações de estilo de bloco de Gutenberg btw.?

@strarsis

Sim, verifique o núcleo button e o bloco quote

https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/button
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/quote

@strarsis Os pullquote , table e separator também têm variações de estilo:
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/pullquote
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/separator
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/table

Eu realmente gostaria de ver alguns blocos organizacionais criados. O problema atual com Colunas é que a criação de um único bloco com coluna para agrupar o conteúdo (digamos, para fins de cor de fundo, vídeo ou imagem compartilhada) não é intuitivo. Eu gostaria, idealmente, de ver o editor atingir o estágio em que fosse capaz de criar conteúdo como esse quase que estritamente dentro do editor.

Movendo isso provisoriamente para uma versão 5.1 para que tenhamos um pouco mais de tempo para definir como esse bloco deve ser apresentado.

Enquanto estou pensando sobre isso ... uma vez que há sobreposição entre isso e o bloco de cobertura, e se o bloco de cobertura fosse mais uma "configuração", quando você adiciona esse bloco, ele realmente adiciona um bloco de seção pré-configurado com um título ou bloco de texto / parágrafo aninhado dentro dele?

@JiveDig

e se o bloco de capa fosse mais uma "configuração", pois quando você adiciona esse bloco, ele realmente adiciona um bloco de seção pré-configurado com um bloco de título ou texto / parágrafo aninhado dentro dele?

Isso soa muito como um bloco reutilizável sendo inserido como um bloco autônomo para mim. Talvez o núcleo pudesse incluir vários modelos de bloco reutilizáveis ​​por padrão como esse. A IU teria que ser aprimorada para facilitar a inserção de um bloco Reutilizável como um autônomo. Veja # 8403.

Haverá uma bifurcação para testar a nova seção / bloco de contêiner? Estou interessado em brincar com ele e ajudar a testá-lo.

Um bloco de contêiner / seção é muito útil, tive que usar o
Bloco de contêiner de blocos avançados de Gutenberg por enquanto.
E é importante tornar o bloco de seção / contêiner facilmente visível e selecionável.

Em parte, comentando para notar que um bloco de seção seria incrivelmente útil para o desenvolvimento de modelos.

Acabamos de criar um bloco de seção personalizado em vez de estar no núcleo e detectamos um problema em que os atributos do bloco não eram atualizados se o bloco permanecesse o mesmo, mas os atributos estivessem mudando.

Isso foi resolvido no PR # 12406 (acima)

O bloco de seção ainda é considerado para 5.1 (previsto para 21 de fevereiro de 2019) ou mais tarde?

Eu escrevi um plugin de bloco de seção, que usei em alguns projetos e espero lançar como algo mais genérico para o repositório de plugin. Permite definir cores de fundo e imagens ou vídeo, bem como uma classe definida por tema para formatar os itens contidos na área innerblocks .

Em meus casos de uso, era mais fácil para o cliente ter campos de título e descrição predefinidos (opcionais) acima de uma área de blocos internos onde eles poderiam empilhar "itens", que, em meu caso de uso, eram pseudo-widgets que eu criei com outro bloco tipo. Mas isso poderia ser facilmente seções aninhadas simples, onde o primeiro bloco de seção continha um título, parágrafo e outro bloco de seção, que por sua vez continha os itens ...

Seções significam que gutenberg _deve_ ser capaz de lidar adequadamente com seções que têm sua exibição definida como flex e renderizar corretamente as propriedades flex dos filhos imediatos.

Eu renderizo minhas seções em JS, mas o código tem uma série do que considero ser hacks. Renderizá-los em PHP seria moleza ... exceto que enviar conteúdo de innerblocks para PHP ainda não foi resolvido, não é?

Colunas, conforme implementado pelo bloco de colunas, é uma solução completamente impraticável porque requer curadoria manual das colunas, o que não é compatível com dispositivos móveis e torna a adição ou remoção de outro item em um conjunto um grande e frustrante aborrecimento.

"Colunas" em uma seção são simplesmente uma declaração de base flexível e podem, e devem, facilmente ser linhas, e não são contêineres reais para itens, mas simplesmente uma definição de como eles fluem. Por favor, não estrague o conceito de seções com algo semelhante a colunas como o (s) recipiente (s) para os itens dentro.

As propriedades definidas em uma seção devem ser facilmente descobertas pelos blocos contidos nessa seção. Devo ser capaz de criar um tipo de bloco que possa responder de maneira inteligente às escolhas feitas no pai, se houver um pai. Do jeito que está, é difícil descobrir qualquer coisa sobre os atributos dos pais sem escrever o que parece ser 1.400 linhas de código.

Os blocos são aninhados porque o contexto pai / filho desses blocos é essencial para como eles são exibidos e editados. Fingir que o contexto não existe é o pior idealismo.

Os blocos aninhados devem ser capazes de referenciar atributos pai facilmente e por padrão. Se o seu objetivo é não ter blocos renderizados do lado do servidor, exceto em raras ocasiões, essa passagem de informações de contexto _tem que acontecer_, caso contrário render() será um deserto de return null como novo e útil mas aparecem blocos complicados.

(Eu acho que o bloco columns seria mais útil se implementasse a propriedade [ainda experimental] CSS columns . Seria essencialmente um tipo especial de section , levando todos os os itens dentro dele e fluindo-os por meio de propriedades de coluna definidas no inspetor: column-width , column-count , column-rule , etc.)

Existe alguma data de lançamento para este tipo de bloco (Adicionar Bloco: Seção)?

@JQOz Não. Esta questão está no roteiro para as próximas versões do prefeito, mas não há nenhuma solicitação aberta de pessoas trabalhando. Se você tiver ideias ou recursos para este bloco, pode começar a adicioná-los aqui.

Oi,

Eu penso nisso não apenas uma vez. Uma seção deve ser um contêiner de largura total. Podemos apenas adicionar uma calha ao contêiner dentro de uma seção e mantê-los funcionando como add_theme_support('alignwide') ou não.

Para um caso:

https://tech.cornell.edu/

Temos muitas seções diferentes. Alguns deles estão vivos em um contêiner. Alguns não são. Mas todos eles precisam de um único contêiner.

Os blocos de coluna de Gutenberg são uma classe de aninhamento demais e não ajudam muito. Deve seguir uma estrutura de grade e usar classe pai> filho para mantê-los funcionando.

Quando eu faço um https://www.luminasolar.com/ desenvolvimento, devo envolvê-los dentro de uma chave template para manter uma estrutura.

Eu sugiro que, como parte da estratégia de layout de página, algum pensamento vá para o fornecimento de um gancho / API para desenvolvedores de temas e plugins de terceiros de construtores de páginas para adicionar suas próprias interfaces e sinos e assobios.

Seguindo este item no WPTavern , parece que os usuários estão começando a ver um problema com a padronização e o bloqueio a blocos específicos para layout, voltando à velha castanha de um problema que tem sido um problema por muitos anos: mudar o tema ou o construtor de páginas e o layout desaparece ou no caso do novo editor de bloco, aparentemente, código que não pode ser alterado porque está gravado na pedra.

Ter um layout padrão comum que CoBlocks, Kadence (ou o que quer que você tenha) pode substituir, resolveria isso. Mude o plugin ou tema e pelo menos seu conteúdo ainda manterá o mesmo layout básico.

Este é basicamente o único recurso que falta que me faz manter o elementor por perto em meus sites ...

Seguindo este item no WPTavern , parece que os usuários estão começando a ver um problema com a padronização e o bloqueio a blocos específicos para layout, voltando à velha castanha de um problema que tem sido um problema por muitos anos: mudar o tema ou o construtor de páginas e o layout desaparece ou no caso do novo editor de bloco, aparentemente, código que não pode ser alterado porque está gravado na pedra.

Ter um layout padrão comum que CoBlocks, Kadence (ou o que quer que você tenha) pode substituir, resolveria isso. Mude o plugin ou tema e pelo menos seu conteúdo ainda manterá o mesmo layout básico.

Sim Sim Sim! Eu acredito que um bloco de seção flexível é a única grande característica que falta em Gutenberg. Fico feliz em saber que está planejado para um lançamento futuro, mas fico desapontado por ninguém estar trabalhando nisso agora. Sem isso, os usuários ainda não podem fazer o layout de formatos de página comuns e os desenvolvedores de tema ainda precisam recorrer a técnicas proprietárias para chegar onde um usuário possa realmente construir um layout de página razoavelmente comum.

O bloco de seção DEVE estar no núcleo do Gutenberg (e configurável e extensível por temas) para finalmente resolver os problemas de ser capaz de criar páginas mais complexas e ainda ser capaz de alternar temas.

Claro, como designer de temas, irei adicionar minha própria paleta de cores, controlar as margens e preenchimento para combinar com meus temas, formatar imagens para combinar e todos esses tipos de coisas de "design" específicas do tema ... mas um usuário deve ser capaz de mudar para qualquer tema WordPress e pelo menos ter seu conteúdo preservado, essencialmente no mesmo layout (seções agrupadas, colunas, etc.), e ser editável como um Bloco de Gutenberg (não ter que mudar para o bloco HTML personalizado).

Eu tenho um plugin de bloco de seção que eu tenho uma versão inicial de trabalho e espero atualizar no final desta semana e enviá-lo para o repositório. Ele permite aninhamento infinito do bloco (quero dizer, dentro do razoável, suponho). O plug-in também permite que temas ou plug-ins definam seus próprios estilos de seção, se desejarem, que podem ser escolhidos pelo usuário. Pretendo incluir apenas alguns estilos padrão, que podem ser desativados por temas, se desejado.

Painéis Inspetores

• _Background._ Meu plugin permite definir a cor de fundo e / ou imagem se desejar, com controles para a colocação da imagem, mesclagem, dessaturação e até sobreposição de uma cor.
• _Dimensões, Preenchimento, Margens._ Por padrão, as seções são auto-ajustadas ao conteúdo e obedecem aos alinhamentos completo, amplo e central, com esquerda e direita em 45%. Dito isso, estarei adicionando controles para permitir uma largura e / ou altura especificadas, preenchimento ao redor dos InnerBlocks e margem ao redor do bloco. _Mas veja abaixo os problemas com Gutenberg._
• _Colunas ... e linhas._ Depois de muita experimentação usando flex, CSS _grid_ para os filhos imediatos é o melhor método a ser usado se você estiver atrás de um layout baseado em colunas. Usar a grade é alternar; caso contrário, os filhos são apenas blocos normais. (Honestamente, embora as linhas sejam viáveis, elas adicionam muita complexidade à interface de edição que pode ser melhor tratada adicionando uma nova seção abaixo daquela em que você está trabalhando quando precisa iniciar uma nova linha.) A grade é superior a flex - mesmo se você estiver apenas criando colunas - porque flex _requer_ uma altura específica, não percentual, a ser definida no contêiner ou nos itens filho, o que remove muita flexibilidade.

Móvel
Um problema com qualquer plugin de seção usando grade é o que acontece com a grade em pontos de interrupção móveis definidos. Os usuários (ou autores do tema) devem ser capazes de definir quando uma seção passa da exibição de 3 itens para 2 itens e 1 item.

Os pontos de interrupção precisam ser definidos pelo tema e não parecem pertencer ao bloco, já que isso adiciona outro grande conjunto de opções de inspetor e você provavelmente deseja que seus pontos de interrupção sejam consistentes em postagens e páginas . Mas ao usar a opção de grade, o bloco precisa saber sobre os pontos de interrupção e precisa permitir que o usuário (ou tema) especifique como o layout da seção se adapta a eles.

Tenho certeza de que há uma maneira elegante de fazer isso, mas a curto prazo, por conveniência, estou simplesmente permitindo que o bloco "aprenda" sobre os pontos de interrupção via configuração e, em seguida, usando uma lista de valores separados por vírgulas para o pontos de interrupção (imagine uma captura de tela aqui):

Columns:        3,2,1,1
Column 1 width: 70%,50% 

Etc. (Obviamente, colunas únicas são 100% e não precisam ser especificadas).

Considerações sobre tema e plug-in
Um tema (ou plugin) pode definir uma seção, com todos os seus atributos, e ocultar todos esses atributos do usuário, salvando-os de possíveis confusões, ou o tema pode expor apenas as coisas que deseja que o usuário possa modificar (por exemplo, a imagem de fundo real escolhida). Temas ou plug-ins também são livres para adicionar floreios usando sua folha de estilo para especificar tipos de seção ... na verdade, em teoria, poderia ignorar todas as minhas caixas de inspeção, ocultar todos os painéis de inspeção do usuário e estilizar coisas inteiramente com sua folha. No entanto, isso remove a possibilidade de os usuários sobreviverem a uma mudança de tema com suas seções intactas.

Considerações do usuário
Assumindo que o tema funcionou bem e usou os vários caminhos disponíveis dentro do meu bloco para definir uma seção e seus atributos "corretamente", se o tema for alterado, todos esses atributos sobreviverão e se o tema até agora os escondeu do usuário, eles ' está exposto. Isso ocorre porque a primeira escolha no seletor de "seção pré-estilizada" é "personalizado", que permite ao usuário modificar tudo e que é o padrão do bloco se o estilo escolhido anteriormente não estiver mais disponível. Todas as configurações feitas pelo tema que NÃO foram escolhas diretas da folha de estilo ainda estarão lá.

Isso não garante que sua seção sobreviva de uma maneira que parece boa (você pode ter um tema com um layout superlargo e mover para um com um layout estreito, então uma seção de seis colunas pode não ser mais a melhor escolha ... mas ainda estará lá intacto. Os usuários podem salvar esse layout como um bloco reutilizável.

Ao escolher estilos de seção, se você passar de uma seção predefinida para uma seção personalizada, os atributos do inspetor da seção predefinida seguem, portanto, é uma maneira de os usuários modificarem uma seção predefinida sem ter que modificar a definição dessa seção no tema ou plugar.

Problemas de Gutenberg
Então, Gutenberg faz o seguinte mal:

• Blocos que precisam ser montados verticalmente, o que você pode às vezes precisar de seções de imagem.
• Qualquer tipo de chamada para exibir algo como flex ou grade. Por causa da sopa div do editor, você deve remover a definição de sua chamada CSS para grid ou flex no invólucro do innerblocks e redefini-lo em um dos blocos do editor.
• Alinhamento à esquerda e alinhamento à direita. Eu criei um bug sobre isso, mas como Gutenberg não limita a flutuação de um bloco esquerdo ou direito apenas ao filho imediato do bloco com o atributo de dados esquerdo ou direito (ou centro), todos os blocos aninhados subsequentes são flutuados para a esquerda ou direito.
• Adicionar novos blocos é frequentemente um mistério completo onde eles serão inseridos ... você acha que está no final da sua seção, querendo um novo bloco interno, e em vez disso o editor irá inserir um no final do seu documento
• O modelo de arrastar / soltar de Gutenberg para blocos móveis não funciona de forma confiável com blocos que podem ter posição horizontal

Experimentando
Vou postar um link neste tópico quando lançar uma versão no github que eu acho que vale a pena olhar, se alguém estiver interessado. Passei alguns meses nisso e provavelmente ainda não é ótimo, mas é alguma coisa.

Devo acrescentar que acredito fortemente que coisas como fontes, tamanhos de títulos, etc, não são coisas sobre as quais o bloco de seção deveria ter uma palavra a dizer diretamente. Os atributos do inspetor que estou definindo me parecem os básicos necessários para preservar os atributos de "visão geral" de uma seção de tema para tema, ou para evitar que a remoção de um plugin prejudique completamente a aparência de um site.

@rogerlos Você deve considerar dar uma olhada nos Blocos Kadence . Eles parecem estar lidando muito bem com as colunas baseadas em flexbox.

Devo acrescentar que acredito fortemente que coisas como fontes, tamanhos de títulos, etc, não são coisas sobre as quais o bloco de seção deveria ter uma palavra a dizer diretamente.

Concordo plenamente com isso. A única exceção seria uma configuração de "cor da fonte" no nível da seção. Isso é necessário porque um site cujas fontes são principalmente escuras não terá contraste suficiente em uma seção que tenha uma sobreposição / imagem de fundo escuro.

Aqui está uma demonstração de como o bloco de Layout de linha do Kadence reutiliza os "Modos de alinhamento" na barra de ferramentas do bloco para permitir três larguras de conteúdo interno diferentes, larguras de coluna ajustáveis, margens de linha superior / inferior ajustáveis, bem como configurações de cor de fundo e texto.

Essas configurações de "largura máxima da seção de conteúdo" são quase os únicos padrões de repetição global (e, portanto, definidos por tema) que um bloco de seção precisa levar em consideração (além das restrições de componente herdadas globalmente, como cores de fonte permitidas, tamanhos de medianiz de coluna etc. )

Vindo da experiência de uma agência da web, não há mais do que três larguras de seção de conteúdo diferentes em qualquer design que recebi. Qualquer coisa fora dessas três larguras tende a ser uma variação específica do conteúdo que intencionalmente rompe com os padrões de design do tema de uma maneira não repetitiva.

Um bom bloco de seção direcionará os usuários aos padrões definidos pelo tema (seguindo os padrões do design original), mas ocasionalmente permitirá que eles se afastem desses padrões de maneira razoável.

Para impor um layout consistente e previsível em todos os tamanhos de tela, nenhum bloco "orientado a texto" é permitido no nível raiz em nossa configuração.

Todos os blocos sem imagem / incorporados devem estar contidos em uma "seção" (Kadence Row Layout) no nível da raiz, o que reforça as larguras de seção do conteúdo do nosso tema, enquanto ainda permite linhas totalmente personalizáveis ​​com qualquer número de colunas, bem como fundo de largura total opções, etc.

Elementos de contêiner também devem permitir elementos de camada para empilhamento (índice z).
Isso permite, por exemplo, um elemento de vídeo ou controle deslizante como plano de fundo ou um efeito de paralaxe.

@strarsis Boa ideia.

Idealmente, um bloco de seção usaria Z-index para fornecer um modo de edição de primeiro plano / plano de fundo alternável.

Desta forma, o bloco de seção em si não reinventa a imagem de fundo / sobreposição, que está disponível no bloco de imagem de capa integrado.

O conteúdo do plano de fundo não seria restringido pela largura e, portanto, os desenvolvedores do tema devem ter a capacidade de definir quais blocos podem entrar em um plano de fundo da seção. A largura do conteúdo de primeiro plano seria restrita a um certo número de larguras máximas fornecidas pelo tema.

Caso o usuário precise se afastar de uma largura padrão dada uma parte específica do conteúdo, ele pode escolher uma seção com a largura seguinte e preencher as laterais de acordo.

As instâncias em que o conteúdo de primeiro plano precisa ser quebrado visualmente fora da largura máxima de uma seção devem ser registradas como uma variação de estilo que ajusta uma margem negativa naquele bloco específico.

A razão para isso é que, embora os usuários se sintam bem seguros ao ajustar os valores de preenchimento, definitivamente não queremos que as margens negativas sejam definidas pelo usuário.

Permitir a definição de margens negativas no editor seria uma bagunça ao responder a diferentes tamanhos de tela, preenchimentos laterais da seção de conteúdo, larguras de sarjeta em certos pontos de interrupção, etc. e, portanto, deve ser fortemente acoplado ao tema / código e exposto como abstrações de nível superior para o usuário final.

Com relação ao controle do desenvolvedor: Existe o plugin Mesh que fornece containers "hard"
que deve ser forçado pelo tema.
Às vezes, um tema deve restringir as áreas disponíveis, como apenas o canto superior esquerdo de toda a página.
Gutenberg deve fornecer um mecanismo para temas para definir esses contêineres "rígidos" dentro de seu editor de página.

@strarsis Na minha opinião, qualquer coisa que aconteça fora da área the_content() não tem negócios dentro do editor de Gutenberg.

Essas "áreas" fazem parte do modelo da página e não do conteúdo da página e devem ser tratadas em outro lugar.

Conteúdo da página x Modelo de página (/ Layout)

O conteúdo / seções dentro do editor deve assumir que o layout circundante não existe (durante a edição) e, em vez disso, deve ser equipado para responder apropriadamente quando colocado dentro de um layout específico (no front end).

Um elemento é parte de um modelo de página ( e não o conteúdo da página ), se:

1. o elemento define ou depende da estruturação, limites ou posicionamento da área the_content() como um todo , e
2. o elemento é parte de um padrão de repetição (ou seja, pode ser visto em dois ou mais permalinks)

Alguns antecedentes baseados na experiência

Os elementos de modelo / layout repetitivos são geralmente específicos para um tipo de postagem personalizada e incluem heróis de conteúdo, barras laterais de conteúdo e rodapés de conteúdo.

Em todos os casos, descobri que o conteúdo desses elementos de layout é suficientemente derivado de informações localizadas em campos personalizados, taxonomias ou outras configurações localizadas no nível da postagem e não no nível do bloco.

E, em todos os casos, reforcei minha crença de que seria um empreendimento incrível modificar em massa ou remodelar novamente essas seções se elas tivessem sido implementadas como blocos no editor de Gutenberg.

Finalmente

A definição (e eventual implementação) de uma Seção só deve se estender o suficiente para lidar com as necessidades dos padrões de design do tema no que se refere a the_content() .

Qualquer coisa que se enquadre em "modelo" e não em "conteúdo" deve ser tratada fora de qualquer bloco de seção e fora do editor de Gutenberg (por enquanto).

Eu quero que Gutenberg seja capaz de fazer modelos inline com o conteúdo tanto quanto todo mundo, mas parece que não estamos lá ainda, e devemos definitivamente terminar este bloco de Seção antes de podermos lidar com os modelos de maneira apropriada.

Alguns dias atrás, eu queria criar um layout básico e precisava disso. Comecei instalando o plugin A, tentei, estava cheio de bugs. Desinstalado, encontrado o plugin B, instalado, tentei seu bloco de seção, foi baaad. O próximo plug-in C com bugs, o plug-in D chamou-o de contêiner e era meh. Próximo plugin E, F .........
Posso assegurar-lhe que o atual "ecossistema" de Gutenberg é muito, muito frustrante se você deseja criar uma página e escrever conteúdo.
O fato de as pessoas aqui ficarem dizendo "olhe para o plugin X", "se você quiser esse recurso, instale o plugin Y" etc. é uma indicação clara de que as pessoas precisam disso. Eles não querem, eles precisam disso. No momento, há uma dúzia de plug-ins, todos com suas próprias implementações de um contêiner / seção / o que você quiser.
Não estou dizendo que Gutenberg deva adicionar todos os recursos existentes, mas este é o básico. Precisa estar lá. Ele não precisa ter todas as opções concebíveis, mas o básico deve estar lá e os desenvolvedores podem estender, se necessário.
Estamos chegando a um ponto em que haverá 20 implementações diferentes para um contêiner básico e nenhuma delas funciona como deveria (opinião pessoal, é claro).

Como uma alternativa fácil, simplesmente usei um bloco de colunas e configurei o número de colunas para 1 (o controle deslizante é limitado entre 2 e 6, mas você pode inserir 1 no campo de entrada). Depois disso, você precisa corrigir o CSS no administrador:

//Allow single columns
add_action('admin_head', 'gutenberg_allow_single_columns');
function gutenberg_allow_single_columns() {
    ?>
    <style type="text/css">
    <strong i="6">@media</strong> (min-width: 600px) {
        .wp-block-columns.has-1-columns > .editor-inner-blocks > .editor-block-list__layout > [data-type="core/column"] {
            flex-basis: 100% !important;
            flex-grow: 0; } }
    </style>
    <?php
}

E é claro que você precisa definir o mesmo em seu frontend também, mas isso é um problema de tema. Acho que permitir um layout de coluna única seria o suficiente para uma opção de contêiner básico, que geralmente é necessária para fins de estilo de qualquer maneira. Qualquer outra coisa (como definir um plano de fundo, z-index, paralaxe etc ...) deve ser feito com plugins imo.

E por favor, adicione um meio para o tema (desenvolvedores) controlar quantos e quais wrappers são usados.
Alguns designs precisam apenas de mais de um elemento. Atualmente, tenho que usar outro plug-in para um elemento de contêiner e, em seguida, analisar todo o conteúdo usando um analisador PHP para empacotar o conteúdo do contêiner em elementos de empacotador extras para estilização.

@strarsis Isso é definitivamente algo que deveria ter sido feito desde o início.

Para fazer qualquer estilo decente do conteúdo da postagem, cada filho no nível raiz deve ser colocado em uma linha / seção consistente.

Por exemplo, sem envolver cada linha, é difícil e complicado fazer seções de larguras diferentes (especialmente seções de largura total).

Também considerei a opção de análise de PHP, mas percebi que ela não dá ao editor de conteúdo nenhum controle sobre o tipo de seção em que um determinado conteúdo está.

Em vez disso, em nossa configuração, forçamos todas as instâncias do editor de Gutenberg a permitir apenas um único bloco Container no nível raiz para qualquer postagem / página / tipo de postagem.

O bloco de contêiner raiz impõe um subconjunto limitado de blocos que podem ser adicionados a ele.

Para adicionar qualquer texto ou blocos de largura não completa, você deve primeiro inserir um Layout de Linha Kadence, que neste caso atua como nosso elemento de empacotamento da seção principal.

Um bloco de contêiner extensível simples é tudo o que deve ser necessário no núcleo. A extensão deste bloco em relação ao estilo deve ser deixada para os desenvolvedores de plugins / temas. Ele também deve fornecer um estado de transformação de fallback para desenvolvedores que desejam construir seus próprios blocos de contêiner.

Todos os plug-ins existentes de terceiros que fornecem contêineres / seções / linhas que testei estão sujeitos a um problema significativo em relação ao bloqueio de conteúdo. Após a desativação desses plug-ins, o conteúdo do bloco interno não fica mais acessível a partir do editor e a conversão remove o HTML. Algo que os usuários devem estar totalmente cientes.

Vejo:
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

Está bem. Eu testei Gutengerg, é bom, mas sim, definitivamente falta a coisa da Seção.
Para ser verdade, muitos blocos têm seu contêiner ao qual podemos adicionar uma classe css e seu estilo. Mas, o conteúdo principal é escrito sem um contêiner, então nem qualquer classe, e portanto não podemos estilizá-lo. E como o conteúdo principal é escrito no mesmo estágio de todos os outros blocos, isso torna extremamente difícil encaixá-lo de forma diferente dos outros.

Em outras palavras, vou voltar ao clássico e esperar até que você nos dê as Seções.

Obrigado, lembraças.

Sim, está absolutamente certo. Acho que é ainda mais importante do que todos os outros blocos em desenvolvimento. @youknowriad Você não pode dar mais prioridade?

Já está no escopo da fase 2 https://github.com/WordPress/gutenberg/issues/13113 se alguém estiver disposto a tentar, por favor, faça.

@youknowriad Não sou um desenvolvedor. Mas lembro que o desenvolvimento já estava em andamento. Pouco antes do lançamento do Wordpress 5 havia um PR que já estava muito avançado. Ainda havia detalhes a serem esclarecidos, mas estava quase pronto. Infelizmente, não consigo mais encontrar o PR. Alguém tem ideia de onde fica?

Sim, não se preocupe, eu entendo.

Aqui está o PR. https://github.com/WordPress/gutenberg/pull/10562

Queria esclarecer que é um projeto de código aberto e é baseado no voluntariado. Posso dar uma direção global, pedir ajuda, mas não designar pessoas. As pessoas tendem a pensar o contrário.

Eu reitero que se houver desenvolvedores que desejam ver isso acontecendo mais rapidamente e querem ajudar, eles são bem-vindos às reuniões semanais no canal Core Slack # core-editor (e reuniões) e discutir / colaborar / pedir ajuda.

Ahhh sim é isso! Ótimo! Você tem uma visão geral !!!

Sim, isso é verdade e não deve ser uma censura. O que simplesmente me perguntei: não há tarefas importantes e ainda mais importantes? Se 50 pessoas precisam de um bloco RSS, mas 1000 precisam de um bloco de contêiner, faria sentido enfocar tudo mais especificamente. O bloco de contêiner não é nada exótico agora. Acho que esta é a _base de todo design_.

Por favor, não entenda mal: você está fazendo um ótimo trabalho. E você, como líder da fase 2, está fazendo um trabalho de primeira classe. É tudo uma questão de foco. Vou brindar isso no próximo slack chat ... ;-)

Muito obrigado novamente!

Obrigado e feliz em esclarecer. Dou-lhes pessoalmente a mesma importância. Uma etapa intermediária para a fase 2 é usar blocos na tela de widgets. Então, mesmo que as pessoas não estejam pedindo um bloco RSS, uma vez que a tela de widgets (que é uma etapa importante para a fase 2) vai usar blocos, se as pessoas não encontrarem o widget RSS que estão acostumadas a usar, elas vão reclamar disso.

Essas duas tarefas são tarefas "médias" em termos de complexidade, são importantes em termos de recursos, mas não são importantes em termos de estrutura. Minha alta prioridade pessoal no momento são as coisas do framework que permitiriam os objetivos da fase 2 (blocos na tela de widgets, editor fora de post_content), já que essas questões conteptuais são importantes para experimentar e esclarecer mais cedo ou mais tarde.

Está bem. Eu testei Gutengerg, é bom, mas sim, definitivamente falta a coisa da Seção.
Para ser verdade, muitos blocos têm seu contêiner ao qual podemos adicionar uma classe css e seu estilo. Mas, o conteúdo principal é escrito sem um contêiner, então nem qualquer classe, e portanto não podemos estilizá-lo. E como o conteúdo principal é escrito no mesmo estágio de todos os outros blocos, isso torna extremamente difícil encaixá-lo de forma diferente dos outros.

Em outras palavras, vou voltar ao clássico e esperar até que você nos dê as Seções.

Obrigado, lembraças.

Esta é a posição que estou assumindo sobre essa e outras deficiências do novo editor de blocos até que ele se adapte. Esperamos que isso aconteça, pois há alguns aspectos interessantes no novo editor.

Um bloco de seção seria incrível, o que posso fazer para ajudar apesar de não ter habilidades de desenvolvimento de backend

Há muitos plug-ins de bloco agora, mas o único bloco deles que quero é uma seção ou bloco de contêiner, então adoraria ver um adicionado.

O núcleo do WordPress precisa incluir sua própria implementação de uma seção, linha, estrutura de layout de colunas para o editor de blocos, algo que seja padrão e que possa ser usado por todos os plug-ins, temas e construtores de páginas de terceiros. Uma API deve ser fornecida, como mencionei muitas vezes antes, para que eles possam adicionar suas próprias interfaces, sinos e assobios. Desative qualquer uma dessas soluções de terceiros e a estrutura da sua página permanecerá intacta.

Como está, existem soluções de terceiros para seções / linhas vindas de todas as direções, mas, uma vez que você começa a misturar blocos de núcleo nativos e blocos de terceiros, você começa a ver muitas inconsistências e bloqueios travando e precisando ser resolvidos. Não que eu queira criticar os esforços daqueles que fornecem essas soluções para layout, eles estão preenchendo um recurso muito necessário. Muitos deles são bons, mas algo não está certo sobre a experiência geral.

Eu sou totalmente a favor de manter o editor de bloco central simples, permitindo que terceiros adicionem funcionalidade extra e sofisticação, mas ele realmente precisa ser aprimorado, caso contrário, obter um pouco de tração em sua aceitação não será alcançado muito facilmente.

A grande questão aqui é quem cuida disso. Não existem alguns desenvolvedores que têm tempo e energia para fazer isso?

Sim Sim Sim! Eu acredito que um bloco de seção flexível é a única grande característica que falta em Gutenberg.

Nem acredito que ainda não existe ...

Uma alternativa seria permitir que o bloco de colunas tenha apenas uma coluna e também permitir a definição de cores de fundo para as colunas. TA-DA: bloco de seção.

Bem, se isso ajuda alguém: escrevemos um bloco de seção para nossos projetos há algum tempo. Tenho certeza de que pode ser aprimorado em alguns pontos, mas pode ser um bom ponto de partida:

https://github.com/Impuls-Werbeagentur/impuls-section-block

Vou colocar minha mão para trabalhar nisso. Eu poderei começar a partir do meio da próxima semana

@chrisvanpatten - parece que você fez um progresso muito bom nisso antes, só queria saber se está tudo bem comigo?

Usei alguns blocos de contêiner de plug-ins. Acho que os principais requisitos são o suporte a um alinhamento amplo e completo, flutuadores e controles para alterar o plano de fundo do contêiner. O objetivo de enviá-lo em uma primeira versão fornecerá uma boa base para melhorias futuras.

Acho que a primeira melhoria é adicionar mais invólucro fora de qualquer bloco.

Por exemplo:

<div class="wp-block-paragraph">
  <div class="wp-block-paragraph__container">
    <InnerContent />
  </div>
</div>

No momento, muitos dos elementos são inseridos diretamente, o que nos impede de aplicar estilos para fazer um invólucro.

<ol>
  <li></li>
</ol>

Pode ser adicionado um wrapper a isso:

<div class="wp-block-listing">
  <div class="wp-block-listing__container">
    <ol>
      <li></li>
    </ol>
  </div>
</div>

Em seguida, podemos aplicar o conjunto de contêineres para mantê-los correspondentes:

// Example
#content > * > * {
  max-width: 1280px;
  padding: 0 20px;
}

@talldan , você se importaria de dar uma
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

Blocos de seção seriam fantásticos, mas, por favor, faça-os apenas marcação semântica! Manter as coisas na estrutura HTML semântica criaria a base de código mais agnóstica.
<section>, <article>, <header> é muito melhor <div class="wp-section"> ou qualquer outra coisa.

@talldan Desculpe, não entendi seu comentário, mas estou 100% bem se você aceitar isso 🙌 Tenho certeza que você vai arrasar!

Também seria ótimo poder usar o ponto focal do bloco de texto e mídia # 10925. Claro que isso só faz sentido se você tiver uma imagem de fundo.

Uma grande coisa, que, aliás, muitos construtores de páginas também têm. Ou pelo menos algo assim:

Concordou que um seletor de ponto focal seria ótimo aqui. Funciona muito bem no bloco de capa!

Com isso em mente, atualizei minhas maquetes anteriores para um bloco de seção. Ele atua puramente como um elemento de contêiner com uma cor de fundo e imagem ajustáveis.

Antevisão :

Você pode verificar o protótipo aqui .

Algumas notas adicionais:

• Acho que devemos lançá-lo sem imagem de fundo para começar, apenas cor de fundo / texto. Depois de empurrar isso para fora, podemos construir a imagem de fundo a seguir. Isso sai rápido, usando padrões existentes, e ainda deve abranger um grande número de casos de uso.
  
  
  
  • Assim que mesclarmos a primeira versão, poderemos potencialmente descontinuar o plano de fundo e a cor do texto do bloco de texto. Em vez disso, poderíamos ter opções de cores / opções de destaque embutidas no bloco de parágrafo. Este parece ser um padrão geral melhor para o parágrafo.
  
  
• Este bloco não conteria nenhuma configuração responsiva, pois seria sempre apenas um container. O conteúdo dentro do contêiner (como um bloco de coluna) forneceria o comportamento responsivo.

Concordo, a imagem de fundo pode ser adicionada usando css se necessário por enquanto: +1:

Assim que mesclarmos a primeira versão, poderemos potencialmente descontinuar o plano de fundo e a cor do texto do bloco de texto. Em vez disso, poderíamos ter opções de cores / opções de destaque embutidas no bloco de parágrafo. Este parece ser um padrão geral melhor para o parágrafo.

Uma das razões para considerar o bloco de seção o lugar certo para as cores do nível do bloco é que, caso contrário, temos que responder por que a lista, o título e outros blocos de texto básicos não têm essas opções de cores. E como eles são divididos no nível do bloco, você nunca seria capaz de ter uma imagem de fundo que abrangesse todos eles continuamente, enquanto um bloco de seção corrige isso.

A maneira de descontinuar essas cores poderia ser apenas remover a IU delas, mas deixar os blocos existentes com o estilo que estão.

Agradável! Seria útil ter classes pequenas / médias / grandes para preenchimento vertical.

Agradável! Seria útil ter classes pequenas / médias / grandes para preenchimento vertical.

Isso mergulha no nível de tema / estrutura e não tenho certeza se o core tem lugar para algo como https://cdn.vaadin.com/vaadin-lumo-styles/1.4.1/demo/sizing-and-spacing .html

Acho que devemos lançá-lo sem imagem de fundo para começar

Não poderia concordar mais. Obtenha uma v1 e então v2 pode adicionar funcionalidades mais complexas.

Este bloco não conteria nenhuma configuração responsiva

Concordado - este Bloco deve ser o mais simples e não preconcebido possível.

Acho que devemos mesclar este PR, se possível.

Eu dei uma pancada em algo assim ... lançado como um plugin:

https://wordpress.org/plugins/magic-block/

Por favor, chega de plugins que deixarão as pessoas dependendo dele. Apenas solte o maldito bloqueio.

@webdados eu

Não é para diminuir o trabalho de ninguém, mas realmente precisamos que isso seja integrado em algum nível.

Especialmente em um mundo onde existe esse problema .

Se uma solução adequada for encontrada para # 13391, então a existência de incontáveis ​​implementações de bloco de contêiner provavelmente seria suficiente.

Até que o novo construtor de bloco rache tendo uma base padrão para elementos de layout (contêineres, seções, linhas e colunas) que plug-ins de terceiros podem estender, então ele não tem nada e perpetua a bagunça de ligar e desligar blocos, temas, construtores de terceiros ( aqueles que tentam resolver o problema de layout) e acabam perdendo conteúdo e layout de página.

Quando podemos esperar esse recurso?

Já deve estar na versão mais recente:
https://github.com/WordPress/gutenberg/releases/tag/v5.5.0

@ksere : Eu perdi isso provavelmente porque o changelog para v5.5.0 do plugin está vazio .

Realmente cavando a implementação disso até agora. Eu entendo que foi lançado no 5.5, mas estou me perguntando quando poderemos esperar adições para imagens de fundo (e seu posicionamento), opacidade de cor de fundo, etc. Isso é algo que devemos esperar antes do final de 2019, ou estamos falando mais tempo -termo do que isso?

@nathansnelgrove Obrigado pelo feedback. Definitivamente, há algumas melhorias chegando ao bloco de grupo, aqui estão duas já em andamento:

• Adicionando um contêiner interno para tornar o estilo mais fácil - https://github.com/WordPress/gutenberg/pull/15210
• Adicionar opções de editor para agrupar / desagrupar uma seleção de blocos - https://github.com/WordPress/gutenberg/pull/14908

Eu não vi os problemas que você mencionou sobre imagens de plano de fundo e opacidade sendo rastreados em qualquer lugar, pode valer a pena criar um problema separado para isso se você tiver tempo, pois esse problema está resolvido.

As imagens / cores / opacidade de fundo são da proposta original - farei um novo problema para elas.

Acabei de instalar o WordPress 5.2.4 e não consigo encontrar nenhum bloco de "Seção" ou "Grupo". O que está acontecendo aqui?

@patrikhuber : Isso será incluído no WordPress 5.3, que está planejado para ser lançado em 12 de novembro.

@noisysocks eu vejo, muito obrigado!