Libsass: Os seletores de tipo devem sempre imprimir antes das classes psuedo

Criado em 30 jun. 2018 · 3Comentários · Fonte: sass/libsass

Ao estender um placeholder de um seletor [type] , se o placeholder usar pseudoclasses, os seletores serão impressos na ordem errada.

input.scss

%button-styles {
  color: red;

  &:focus {
    color: blue;
  }
}

[type="button"] {
  <strong i="8">@extend</strong> %button-styles;
}

Resultados reais

libsass 3.5.4

[type="button"] {
  color: red;
}

:focus[type="button"] {
  color: blue;
}

Resultado esperado

ruby sass 3.5.6

[type="button"] {
  color: red;
}

[type="button"]:focus {
  color: blue;
}

informação da versão:

$ node-sass --version
node-sass   4.9.0   (Wrapper)   [JavaScript]
libsass     3.5.4   (Sass Compiler) [C/C++]

Também executei algumas instruções de depuração com selector-unify e notei que se usei um seletor de elemento, ele unificou conforme o esperado, independentemente da ordem, mas o seletor de tipo não o fez.

@debug(selector-unify('button', ':focus'));
// button:focus

@debug(selector-unify(':focus', 'button'));
// button:focus

@debug(selector-unify('[type="button"]', ':focus'));
// [type="button"]:focus

@debug(selector-unify(':focus', '[type="button"]'));
// :focus[type="button"]

Avise-me se houver mais informações que eu possa fornecer!

Bug - @extends Bug - Confirmed Dev - Test Written

Fonte

ashleykolodziej

👍6

Comentários muito úteis

Este é um bug muito
https://www.sassmeister.com/

Ok, eu tive um brainfart ontem, meu exemplo abaixo na verdade não é um bug (ou pelo menos a ordem não importa nesse caso).
Mas o bug original ainda está de pé.

~~Eu também fiz alguns testes, e há mais maneiras de extends com classes dentro deles, também serem impressos na ordem errada:~~
Libsass:


%testextend {
  background: red;
  &.hoverclass {
    background: blue;
  }
}

%testextend {
  background: red;
  &:hover {
    background: blue;
  }
}

.wrapper {
  &.inner {
    <strong i="15">@extend</strong> %testextend;
  }
}

Resultado:


.wrapper.inner {
  background: red;
}

.hoverclass.wrapper.inner {
  background: blue;
}

.wrapper.inner {
  background: red;
}

.wrapper.inner:hover {
  background: blue;
}

~~Como você pode ver ... a classe flutuante é impressa como a primeira classe.~~
~~Na verdade, descobri que meu exemplo também é um bug na biblioteca normal do sass.~~

bskibinski em 4 out. 2018

👍3

Todos 3 comentários

Este é um bug muito
https://www.sassmeister.com/

Ok, eu tive um brainfart ontem, meu exemplo abaixo na verdade não é um bug (ou pelo menos a ordem não importa nesse caso).
Mas o bug original ainda está de pé.

~~Eu também fiz alguns testes, e há mais maneiras de extends com classes dentro deles, também serem impressos na ordem errada:~~
Libsass:


%testextend {
  background: red;
  &.hoverclass {
    background: blue;
  }
}

%testextend {
  background: red;
  &:hover {
    background: blue;
  }
}

.wrapper {
  &.inner {
    <strong i="15">@extend</strong> %testextend;
  }
}

Resultado:


.wrapper.inner {
  background: red;
}

.hoverclass.wrapper.inner {
  background: blue;
}

.wrapper.inner {
  background: red;
}

.wrapper.inner:hover {
  background: blue;
}

~~Como você pode ver ... a classe flutuante é impressa como a primeira classe.~~
~~Na verdade, descobri que meu exemplo também é um bug na biblioteca normal do sass.~~

bskibinski em 4 out. 2018

👍3

@bskibinski Não estou

ashleykolodziej em 5 out. 2018

@ashleykolodziej Haha feliz dia do bolo! Que bom que pude fazer melhor;)

Além disso, minha segunda descoberta de bug não é realmente um bug (longo dia), mas o seu ainda é!
Esperamos que isso seja corrigido em breve! :)

bskibinski em 5 out. 2018

Esta página foi útil?

0 / 5 - 0 avaliações