These are chat archives for japgolly/scalacss

7th
Mar 2015
SRGOM
@SRGOM
Mar 07 2015 03:55
Thanks for doing this, I didn't see a reference ot media styles- screen-size/orientatoin/print etc. I read the requirements and see point FR-04 (able to define a style that depends on the current plaform (eg. IE 8, mobile)), I just want to make sure that FR-04 includes that, is that so?
David Barri
@japgolly
Mar 07 2015 07:00
Added FR-{18,19}.
@SRGOM np! Yes, FR-04 will include media-styles. I foresee them being specifiable in both CSS media queries and JS introspection of the environment.
Malchevskiy Misha
@malchmih
Mar 07 2015 08:01
I know simular project in Clojure: https://github.com/noprompt/garden. You can probably get some ideas from it too
Otto Chrons
@ochrons
Mar 07 2015 08:31
how about enabling wiki on the repo for easier modification by interested parties?
Otto Chrons
@ochrons
Mar 07 2015 09:03
do pseudo-elements like ::before work with inline styles?
so you would need to use embedded CSS and id-selector
Otto Chrons
@ochrons
Mar 07 2015 09:16
same for all pseudo-selectors like :nth-selector for coloring odd row numbers for example
auto-selection of browser specific style names would be nice, so instead of having -webkit-transform, -moz-transform and transform, just plain transform would be enough
Otto Chrons
@ochrons
Mar 07 2015 09:22
nobody likes this in their code :)
.elementClass {
    -moz-border-radius: 2em;
    -ms-border-radius: 2em;
    -o-border-radius: 2em;
    -webkit-border-radius: 2em;
    border-radius: 2em;
}
would SVG CSS be supported, or does anyone even use it for anything?
Alberto Paro
@aparo
Mar 07 2015 09:35
We need also a translation service to recovery some “history" made css/less/sass.
Otto Chrons
@ochrons
Mar 07 2015 09:38
keyframe animations also require embedded or external CSS
of course embedded doesn't have to be <style>blaa</style> because we can manipulate the CSSOM directly through document.styleSheets
Per Wiklander
@PerWiklander
Mar 07 2015 12:25
Is the thought that this lib is 100% in the browser? Or can we get something nice out of it for server side rendering as well?
It should be possible to get the “compiler checked type safe css” part, even if it ends up being compiled into a css file like less does.
Otto Chrons
@ochrons
Mar 07 2015 13:20
how would it be used i.e. in Play templates?
Justin du Coeur, AKA Mark Waks
@jducoeur
Mar 07 2015 14:46
To @ochrons earlier point, I would suggest two items for the requirements list: it must provide a way to support engine-specific CSS elements (which might be a restatement of CS-05?), and it would be preferable if it provides a mechanism so that the programmer can just specify a common version, and the system produces all the stupid variants.
Otto Chrons
@ochrons
Mar 07 2015 15:59
since the system knows on which browser it's running, it doesn't have to produce all variants
Per Wiklander
@PerWiklander
Mar 07 2015 20:19
@ochrons I'm using scalatags serverside, so currently that environment is very close to scalajs-react.
Except the fact that there is no react of course.
So if client side gets super awesome css support and I still have to support some old css crap server side it will make my hair even greyer than it is.
David Barri
@japgolly
Mar 07 2015 22:27
@ochrons Problem with the wiki is that its online-only and not audited. If we stick to just git and people contribute via pull requests, we have a clear log of changes, don't lose anything and can browse/edit it offline. In a cafe. Which I'll probably do this coming week :)
k3d3
@k3d3
Mar 07 2015 22:30
IIRC, isn't the wiki itself run on top of its own git repo?
David Barri
@japgolly
Mar 07 2015 22:33
Really? I can't confirm or deny that. Don't know. I wouldn't like 2 separate repos. I'm not aware of any advantages in using a wiki over using markdown files in a single repo. :sheep:
k3d3
@k3d3
Mar 07 2015 22:33
yeah, if you make a wiki you can clone it from japgolly/scalacss.wiki.git instead of japgolly/scalacss.git
I think the main benefit is just the interface
David Barri
@japgolly
Mar 07 2015 22:33
Interface for reading or contributing?
k3d3
@k3d3
Mar 07 2015 22:34
more for reading, however for contributing it's a bit nicer too, since you can use the web interface instead of pulling, editing, committing, pushing
I have nothing on here at the moment, but it has a ToC thing at the side, and for me I have an Edit button, amongst other things (I don't know very much about the wiki system)
David Barri
@japgolly
Mar 07 2015 22:36
You can do that for normal files in the repo to. Eg. you can open README.md online, hit the little pencil button, edit directly then hit update. Forking, branching, submitting a PR is all done for you automatically.
k3d3
@k3d3
Mar 07 2015 22:36
oh, interesting
David Barri
@japgolly
Mar 07 2015 22:37
Yeah sometimes I edit my own stuff online cos it's just easier - even tho I have the exact file sitting on my computer lol
k3d3
@k3d3
Mar 07 2015 22:37
heh
David Barri
@japgolly
Mar 07 2015 22:37
It's really, really good for fixing typos in other people's repos too. Takes 2 sec.
k3d3
@k3d3
Mar 07 2015 22:37
yeah, I've done that before too
hmm, so it looks like by default anyone can edit wikis, but you can also change it to only be editable by contributors, and at that point there's no automatic fork and PR thing
so at that point, if you want to control edits, I suppose I'd suggest using a regular repo
David Barri
@japgolly
Mar 07 2015 22:40
I think you're right. Plus having two repos for the same project makes me cringe.
k3d3
@k3d3
Mar 07 2015 22:40
yeah true
David Barri
@japgolly
Mar 07 2015 22:41
I like all related stuff together hehe :)
Anyhoo...
k3d3
@k3d3
Mar 07 2015 22:41
sometimes I wish there were integrated issue trackers, etc. within the repo
or even some standardized format for them
nonetheless, single repo it is!
David Barri
@japgolly
Mar 07 2015 22:42
Yes!!!!
An in-repo issue tracker would be awesome!
No one does it. The closest you find a just offline ones you know they won't handle merges. Even the ones that don't use binary blobs for storage would still merge fail because they all just increase the next issue number. Do that on two branches and you'll end up with two separate issues with the same id.
I considered writing one but I realised I don't have the time and you can come a long way with just markdown files so I abandoned the idea.
It'd be cool if github solved it.
k3d3
@k3d3
Mar 07 2015 22:45
yeah
and it would be fairly simple to solve merge conflicts
David Barri
@japgolly
Mar 07 2015 22:46
yeah
@ochrons Autoselection of browser-specific keys is genius!!! That's a very good idea. I was imagining we'd have a simpler version of 'garden' (thanks @malchmih for the link!) and we still can for fallback, but I think this browser-prefix autoselection would be great!
k3d3
@k3d3
Mar 07 2015 22:46
give each issue message a UUID and a timestamp - for each new issue, reference a previous UUID, and if two issues reference the same previous UUID, keep both and order by timestamp
David Barri
@japgolly
Mar 07 2015 22:46
yeah it would absolutely be possible
@ochrons What do you mean by SVG CSS? I imagine you could apply it to SVG the same way you would to HTML if that's what you mean?
@aparo Re: a translation service to migrate legacy CSS. That's out-of-scope for my work on this project. If somebody else contributed it, it could live in the project no problem. Problem is you won't want a direct translation. The styles that I imagine used when using this project should (hopefully) be more logically what a human would call a style, instead of a browser or a technician. A direct translation would mean you were only using this lib to half of its benefit (which ppl are free to do).
David Barri
@japgolly
Mar 07 2015 22:54
@PerWiklander I don't want your hair going greyer, so much so that I'm considering making that a formal requirement! :D This will be decoupled from scalajs-react, you'll be able to use it with scalatags (although someone will need to provide a little adapter for scalatags). You should will also be able to use it on the server-side with plain Scala.
k3d3
@k3d3
Mar 07 2015 22:55
so is this meant to be fully integrated with scalatags or can you use it on its own? (i.e. use scalacss to output a plain .css file, and maybe reference classes from scalatags)
David Barri
@japgolly
Mar 07 2015 22:56
This won't have any knowledge of scalatags, scalajs-react, etc. It should have zero HTML/CSS-related dependencies.
k3d3
@k3d3
Mar 07 2015 22:56
@ochrons's spa-tutorial has a dependency on sbt-less, which itself has a dependency on npm/node, which I'm not very fond of in a Scala application, so even if scalacss were something as simple as a type-safe DSL that output CSS, I'd be happy with that
David Barri
@japgolly
Mar 07 2015 22:57
Well yep, I imagine that you should be able to generate a static CSS file, just like with SASS/LESS.
But there will also be nicer support (though adapters) for scalajs-react, so that you can apply styles directly to your react code and there will be a single function that you run on page load to install the styles.
(ie. static CSS is possible but optional.)
k3d3
@k3d3
Mar 07 2015 22:58
ah, that's good
I could imagine support in scalajs-react being something like replacing css class strings with actual references to some scalacss variable defining a css class
David Barri
@japgolly
Mar 07 2015 23:00
Exactly! :D
It will look like you're using inline styles, but under the hood it won't be.
k3d3
@k3d3
Mar 07 2015 23:00
oh, that would be even more awesome
David Barri
@japgolly
Mar 07 2015 23:01
It also means that if for performance or whatever, someone can add some rules like "oh I want all the font-weight stuff applied inline in a style="" attr" or whatever.
Probably won't happen but the flexibility to allow it is important I think.
k3d3
@k3d3
Mar 07 2015 23:01
oh yeah, for sure
David Barri
@japgolly
Mar 07 2015 23:02
Or someone could even apply everything inline except psuedo-selector stuff.
k3d3
@k3d3
Mar 07 2015 23:02
being able to use Scala across the entirety of html, css, javascript (and server, plus html/css/js generation there) should likely be able to give a huge amount of flexibility over how things (especially styles) are applied across the board
David Barri
@japgolly
Mar 07 2015 23:06
That's true.
David Barri
@japgolly
Mar 07 2015 23:13

@jducoeur I would suggest ... it must provide a way to support engine-specific CSS elements (which might be a restatement of CS-05?)

Agree. I will add this as FR-20 and restate this as:

For styles that require repeated declaration with different keys (eg -moz-), Dev shall be able to specify the style and its variants with a single declaration.

k3d3
@k3d3
Mar 07 2015 23:15
there could be some middleware way of doing it too, for example if linearGradient() sets box-gradient, calling vendor(linearGradient()) could transform the input and return all of the vendor-specific versions
David Barri
@japgolly
Mar 07 2015 23:17
I'm not sure how it will look but there'll need to be a bunch of rules in there somewhere about which attributes need which prefixes and which platforms correspond to which. Is that what you mean?
k3d3
@k3d3
Mar 07 2015 23:19
Most of the time the vendor prefixes are pretty standardized, i.e. blah for firefox is typically -moz-blah, -webkit-blah for chrome, etc. and you could use that to your advantage and make a simple transform. On the other hand, that's true - not every class will require every single vendor prefix, and defining all of them would be pretty wasteful
David Barri
@japgolly
Mar 07 2015 23:20
Yeah I'd prefer some lookup or something if we can. Unless a dev creates a custom CSS key (which they can) I think it'd be good that all keys are known to be valid.

Speaking of which, I believe I'll add this too:

PR-04: When generating CSS, if the target platform is known, certain vendor-specific CSS keys (FR-20) can be omitted.

(although that wording needs fixing)
This should do: PR-04: When generating CSS, if the target platform is known, Solution should omit unapplicable platform-specific CSS (FR-20).
k3d3
@k3d3
Mar 07 2015 23:23
So if I understand that correctly, the copies with the vendor prefixes will be added by default?
David Barri
@japgolly
Mar 07 2015 23:23
Undecided :)
Probably though.
k3d3
@k3d3
Mar 07 2015 23:23
ah :P
David Barri
@japgolly
Mar 07 2015 23:24
Like you just specify border-radius once and if the platform is known it uses the right prefix, if your own the server-side use all predetermined prefixes
k3d3
@k3d3
Mar 07 2015 23:24
yeah, that makes sense
does javascript allow you to make css classes on the fly?
David Barri
@japgolly
Mar 07 2015 23:25
One way or another: yes.
Hopefully we can just generate a <style> element and done!
k3d3
@k3d3
Mar 07 2015 23:26
heh, all of the examples I see on the net are basically writing out a style element
yeah
David Barri
@japgolly
Mar 07 2015 23:26
hehe
k3d3
@k3d3
Mar 07 2015 23:27
I was half-hoping there was some document.createCssClass() method, with other methods to add and modify styles within that class :P
David Barri
@japgolly
Mar 07 2015 23:28
There might be! I'm a bit shit at pure JS and DOM. There is much I don't know :D
k3d3
@k3d3
Mar 07 2015 23:28
heh
https://developer.mozilla.org/en-US/docs/Web/API/Document/styleSheets well there is this, but it states that it's read-only
also apparently in the works is a CSS object model, similar to DOM
David Barri
@japgolly
Mar 07 2015 23:29
cool, i'm off to breakfast! Thanks for the chat and ideas! See u later!
k3d3
@k3d3
Mar 07 2015 23:29
no problem, it was fun! Take care!
actually this CSSOM thing looks completely different to what I thought it was - maybe not
and document.styleSheets doesn't even appear to allow cross-domain access... pretty useless
so it looks like you're stuck (for better or for worse) with building and maintaining <style> tags :P