Support CSS files for style tags and attributes

[npeltier]

original message in https://lists.apache.org/thread.html/rbf853d99ccdb7e4259231abfcfc11e9c4469ced6095e859027ba4ed2%40%3Cdev.sling.apache.org%3E

certain components require that we overcome beautiful concept of separation
of concern between CSS & HTML as variability of the potential styling is
too high.
This makes us developer forced to add style tag or attribute, together with
inner htl scripting logic, that has been designed to template HTML, but is
a bit too loud for CSS rules.
My proposal is that we extend HTL only for that purpose to parse CSS files
that could be included in style tag or attributes, with similar loop & if
logic, maybe in a different syntax to keep the CSS valid, so to have
something like [0]. Please consider proposed syntax as symbolic, we can
discuss that later if there is an agreement on the proposal itself.
We could also have existing css compilers like less or sass but that might
be overkill and this would lead to lot of frustration as we wouldn't
implement everything.

result would be inline css in style tag / attribute (so only HTML, cf. #89 (comment))

[0]
OLD (not counting the CSS in the models):
<style>
<sly data-sly-repeat.item="${model.definitions}">
${'#{0}' @ format=model.id, context='styleString'} > .items {
<sly data-sly-test.output="${item.show}">
  ${definition.width}
  ${definition.minHeight}
  ${definition.order}
</sly>
}
<sly>
</style>

NEW:
<style data-sly-include="style.css"/>
and
style.css:
# sly-repeat.item="${model.definitions}"
  #'$model-id' > .items {
    # sly-test.output="${item.show}
    width: $item-width;
    min-height: $item-minHeight;
    order: $item-order
    # /sly
}
# /sly```

[justinedelson]

@npeltier are you thinking that the resulting HTML would have an inline style? I.e. would both of these basically result in the same rendered HTML?

[npeltier]

@justinedelson yes

[justinedelson]

@npeltier maybe just me, but I think it would make sense to reflect that in the description above. I read this as something where the context (the model, etc.) would be passed across HTTP requests.

[justinedelson]

Leaving the implementation details aside, I wonder if it would be a better approach from a "specification" approach to simply require that the context be passed into a LESS/SASS/SCSS runtime. AFAIK, all of those support the necessary flow control statements and variables to do what is being described here. WDYT?

For example:

<style data-sly-include="style.sass"/>
and
style.sass:
@each $item in $model.definitions {
  #{$model.id} > .items {
  @if $item.show {
      width: $item.width;
      min-height: $item.minHeight;
      order: $item.order
    }
  }
}

I'm no SASS expert, so this may or may not be 100% accurate.

[npeltier]

i like it, but that has two "flaws" one is we get two syntaxes for expression (even if sass one is very well known by developers), the other, still leaving implementations details aside :-) is we would probably not port the whole sass syntax, and this could be confusing.
this said i'm not sure which way to go :-)

[justinedelson]

This is all just my 2 cents, but what works well in HTL is that doesn't really define a special syntax, e.g. it's just data attributes, and basically looks like HTML. What I'm having a negative reaction to in the original proposal is that it doesn't look like CSS anymore. Now my suggestion doesn't look like CSS either :) but it looks like Sass (and I think the same would more or less apply to LESS).

we would probably not port the whole sass syntax

I wouldn't actually suggest that any Sass syntax be part of the HTL spec. This should just be about how variables get passed into the Sass compilation context (not sure that's the right term, but whatever the mechanism that the Sass compiler supports for passing in variables, assuming such a thing exists).

[tripodsan]

I agree with @justinedelson, using a crippled version of the data-sly attributes in some CSS-ish way is totally counter intuitive and I don't think that anyone would understand how to use it (or even use it).

especially for CSS, there is tons of clientside and buildtime support with languages that are widely adopted.

---

I also think that semantically it is wrong to generate different styles based on the runtime content, I can hardly see a usecase outside the <style>..</style> block.

maybe one use case would be to generate dynamic style sheets in the context of a theme-generator...but even there, I would rather have a robust sheet in less or sass based on variables that can be styled.

[npeltier]

yeah, only style tag (and attribute) context for sure. For the rest node based build chains do the job (far) better.
i guess if sass gets popular here (i'm fine with it too), we would have to talk about implementation, at least for java implementations ;-)

[paul-bjorkstrand]

@npeltier, an apache licensed impl was made by vaadin, though it appears to be unmaintained. There is also an Antlr4 grammar for scss (also appears to be very old/unmaintained).

[npeltier]

thanks @paul-bjorkstrand but as you said it looks pretty old/unmaintained. I've changed the topic to something closer to the implementations details :)