Syntax - considerations

[lucasconstantino]

As I understood, you are indeed creating another syntax for stylesheets. Although I consider this might be justifiable, we have to keep in mind some problems it brings:

• Editors are not prepared to your expressions;
• Preprocessors will have a hard time compiling it.

I'm sure there more issues that can be brought up on this topic. Therefore, unless we plan on building plugins for a considerable amount of editors and preprocessors and syntax highlighters or whatever, we should address the possibility of rethinking the syntax to be CSS compliant somehow.

I'm not here to bring you some solution anyway. But I would like to show an example of things that could be build using compliant syntax. For instance, the code below would fail to compile using Sass:

foo {
  bar: ||mouseY-25||px;
}

whilst the following would get properly compiled:

foo {
  bar: dss("mouseY|px");
}

Again, just an example of something that works. We should definitely discuss more on the topic before defining any syntax or pattern to go forward with.

[raphaelivan]

👍

[felipegtx]

I agree on the need of a more friendly syntax. I'd say that something along the lines of !dss (inspired by !important) would be easily parsed by the library but would also be discarded by the browser as the default value for the element:

.box {
  top: 30px !dss:mouseY; 
}

Perhaps using something like the following would allow both a simple parsing process and a default value to be loaded by the browser (useful for scenarios where the user doesn't allow scripts to run by default).

.box {
    width: 50px;
    height: 50px;
    background: red;
    position: absolute;
    top: 30px;

  /*Magic happens here.*/
   top-dss: mouseY;
}

[guisouza]

Every syntax suggestion will be welcome, but it must respect the following aspects :

• CSS parser, must 'think' that the expression in just an invalid value input.
• Expressions must ONLY appear in CSS values NOT in properties.
• Must support DSS expression and a default value :

background : ||myIdentifier:#F00||;

NOTE : I don't like the current syntax .

[felipegtx]

@guisouza I might be wrong but from what I see, the points you've provided are not supported by the lib yet, right?

About the points, my considerations are:

• Agreed!
• I'm not sure I understand what you're trying to say here. Is it that you expect not to create new properties for DSS to work?
• Also, 100% with you on this (hence my suggestion above)

PS: I'd be willing to give it a try to work on a alternative syntax for the lib whenever we agree upon a format. 👍 Nice job BTW!

[guisouza]

@felipegtx
FOA thanks =]

trying to be clear :

/*CSS SYNTAX*/
selector{
 property:value;
}

DSS properties mus only appear in css values ..
not in properties. =]

[felipegtx]

Yep, that's what I though. I just don't get why? Would you mind to elaborate on that? 😕

[guisouza]

hm ..

/*How this ... */
.box {
    top: 30px;
  /*Magic happens here.*/
   top-dss: mouseY;
}
/*could be better than this ... */
.box {
    top: ||mouseY:30||px;
}

[guisouza]

/*this*/
.box {
    top: 30px;
    top-dss: mouseY;
}
/*and this */
.box {
    top-dss: mouseY;
    top: 30px;
}
/*would generate a different result ..  */

and it would add complexity to my parsers and evaluators

[felipegtx]

Well

This properly sets the default value for element's top as 30px and allows the parser to search for _-dss_ properties and apply some late binding on the target element(s).

.box {
   top: 30px;
   top-dss: mouseY;
}

This does nothing - it's just ignored as an invalid attr-val combination

.box {
    top: ||mouseY:30||px;
}

[felipegtx]

Now, about the order of attributes, IMHO from the point of view of the parser (that updates element's properties in runtime), the order in which the attributes are set shouldn't be a problem. That said, both

.box {
    top: 30px;
    top-dss: mouseY;
}

and

.box {
    top-dss: mouseY;
    top: 30px;
}

should compile the same and produce the same results.

[ShaggyDude]

This is a really cool project.
One thing that I have really needed in the past (besides a parent selector) is a way to detect if a div is 'overflown' that is the content is bigger than the max-height and needs to reflow somehow.

ex.

if this height is greater than this max-height then add class .is-overflown or .has-overflow.

Is this possible with the existing code?
If not does anyone else see the need?

thanks.

[felipegtx]

@guisouza, regarding the worries about the added complexity to the parser and evaluators, I might be (VERY) wrong here, but it would only result in changes on both value and the property patterns.

[guisouza]

@ShaggyDude Todays logic, only cover CSS, not the DOM itself ...
It doesn't even know the existence of a div or something that matches that selector .. =[

[guisouza]

@felipegtx if u could, fork, build a POC and PR ...
call me on any doubts..

[felipegtx]

@guisouza Here you go: http://felipegtx.github.io/dss/example/dss.html

[felipegtx]

I think I'm done for now.

@lucasconstantino you might like to know that with these changes you can compile using SASS

[albertossilva]

Did you consider something like this?

element {
  background: blah;
}

element:dss {
  top: mouseY
}

[felipegtx]

@albertossilva, I didn't quite understood what you said.

My proposal was basically this

.box {
    background: red;
    background-dss: companyColor;
}

[albertossilva]

I proposed a pseudo-selector:

.box:dss {
}

[guisouza]

+1

[leocavalcante]

What about CSS4 syntax?

.box {
  background: var(--company-color);
}

Declaring in a pseudo DSS class

:dss {
  --company-color: red;
}

https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables

[felipegtx]

@leocavalcante don't think this hack with pseudo class is a good idea. Mostly because AFAK there's no standard on whether to ignore or apply the values for unknown values in then.

[leocavalcante]

@felipegtx You are right, custom pseudo-classes will not be applied, but my idea was to work with AST or maybe PostCSS, developing a custom interpreter for this custom selector.

[felipegtx]

@leocavalcante if they are not applied, I think that's the best case scenario - even desired I'd say.

Also, I think that if we're talking about processors, then we can go crazy and create anything fearlessly. 😎

[leocavalcante]

@felipegtx Yeah, using AST is on discussion at #15 I also think is the best scenario for the project.

[guisouza]

I think its a good idea ..
Keep focus in the syntax, AST implementation isn't necessary for a change in DSS syntax .
I think we could focus on the parser after defining a final syntax .
I will test the proposed syntaxes .

[guisouza]

Now we have three different declaration flavours :

pseudo :dss selector

.box:dss{
    left : mouseX;
}

-dss property

.box{
    top-dss : mouseX;
}

old fashion

.box{
    left : ||mouseX||;
}

Thanks everyone for your time and attention

❤️❤️❤️

this issue will be closed for a while =]