On Tuesday, 22 April 2014 at 23:45:43 UTC, Aleksandar Ruzicic wrote:
> Wow, this looks really nice! It has variables, mixins, nested selectors and includes.. That's all I need!

Yea, I wrote this several years ago before even knowing about sass based on what annoyed me about CSS and it looks like me and the sass people had a lot of the same complaints because our results are almost compatible. I think sass does a better job with calculations but meh, I just use box-sizing: border-box and then I don't care as much about calculations anymore anyway!

> Ideally I would use @ as prefix, but that may interfere with CSS @-rules (I see you have CssAtRule class to handle those), so I'd use some character that's easier to type like $ (but that is used for parent selector in upcoming CSS 4)...

Yeah, that's why I picked the weird symbol, I wanted something that wasn't going to be used anywhere else in normal CSS so it wouldn't conflict. (The implementation here is stupid simple: it just does indexOf this symbol and then replaces it. The denesting is a more complete css parser, but the macros replacement is plain text search.)


Anyway, I updated the github to allow $ to be used.

On Wednesday, 23 April 2014 at 04:08:20 UTC, Rikki Cattermole wrote:
> Any chance to get this separated out just for the css part of it?

Hmm, you know, maybe that wouldn't be too hard. I thought it used dom.d's css parser but it actually doesn't! So I could probably write a little css module that doesn't depend on the others (except color.d).

I might work on it tonight.

> And ugh can I change that weird symbol to '$'?

Use std.array.replace to change it before passing to the macro system. There's just the problem then that $ is a fairly common symbol so it will conflict with some other stuff.

On Wednesday, 23 April 2014 at 13:22:02 UTC, Adam D. Ruppe wrote:
> On Wednesday, 23 April 2014 at 04:08:20 UTC, Rikki Cattermole wrote:
>> Any chance to get this separated out just for the css part of it?
>
> Hmm, you know, maybe that wouldn't be too hard. I thought it used dom.d's css parser but it actually doesn't! So I could probably write a little css module that doesn't depend on the others (except color.d).
>
> I might work on it tonight.

Thanks! I will be looking forward to it on the dub repository.

>> And ugh can I change that weird symbol to '$'?
>
> Use std.array.replace to change it before passing to the macro system. There's just the problem then that $ is a fairly common symbol so it will conflict with some other stuff.

Okay, doesn't look too bad of a deal that.

On Tuesday, 22 April 2014 at 21:21:13 UTC, Aleksandar Ruzicic wrote:
> On Tuesday, 22 April 2014 at 12:27:23 UTC, Dicebot wrote:
>> On Tuesday, 22 April 2014 at 06:53:41 UTC, Jacob Carlborg wrote:
>>> On 21/04/14 23:33, Dicebot wrote:
>>>
>>>> I think it is very important to dogfood here and add any currently
>>>> missing dependencies as dub packages instead.
>>>
>>> Unless we can use libsass, I would say it's not very productive to implement a new Sass compiler, just to avoid a dependency.
>>
>> I think using libsass is superior to using node/npm based dependency. Using pretty much anything from node.js infrastructure will be a big marketing hit for vibe.d (being its direct competitor in D world).
>
> I see what you mean. I get that it wouldn't be good marketing so I decided not to use npm.
>
> Although I would really like if we could do dub install -g <package> to distribute tools, like you can with npm..

You can do `dub fetch package; dub run package` AFAIR for packages that are applications. Though it does not make any sense to add something that is not a D  project to dub, such a popular thing as sass compiler must have own package, whatever distro dlang web server runs on.

On 4/23/14, 4:30 AM, Kagamin wrote:
> On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu wrote:
>> https://www.google.com/search?q=page%20width%20study#q=optimal+page+width+for+reading&safe=off
>>
>
> The first link say 100 characters per line. If 100 characters equal to
> page width, then page width is the optimal line length.

Maybe Google personalized my search, but the first hit is http://graphicdesign.stackexchange.com/questions/13724/recommended-column-width-for-text-reading-digital-vs-printed pointing to a study indicating 95 characters per line as optimal for on-screen reading comprehension. The subjective preferences, however, was biased toward smaller numbers.

The second link is http://baymard.com/blog/line-length-readability which points to a few studies concluding that 50-75 cpl (characters per line) would be indicated for web design.

Third is http://stackoverflow.com/questions/7460041/whats-a-good-maximum-width-of-text-on-a-webpage which quotes a really nice collection of numbers from Smashing Magazine from popular websites, showing that 84% of the sites they looked at use 65-104 cpl.

It just struck me that Google's own search page that I'm looking at right now, which I vaguely recall did not limit line lengths a few years ago, is now using a 90 cpl limit. The page's right-hand side is a white area.

Next is http://webstyleguide.com/wsg3/7-page-design/6-page-width-line-length.html, which mentions 66 cpl as optimal from a physiological standpoint.

Next is http://socialtriggers.com/perfect-content-width/ which nicely advocates smaller cpl at the top of the content (so people read the essential message quickly) followed by 100 cpl.

And so on and so forth.

====

So I'd dlang.org to foster a behavior depending on the available real estate, as follows:

* Cap cpl at e.g. 110 on very large screens.

* As the available width decreases, reduce cpl up to 60.

* If cpl with sidebar falls below 60, remove the sidebar and obtain e.g. 80 cpl.

* As the available width reduces further, allow reduction down to e.g. 35 cpl, and then require horizontal scrolling.


Andrei

On 4/23/14, 3:13 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Wednesday, 23 April 2014 at 03:20:18 UTC, Andrei Alexandrescu wrote:
>>> Trying to be clever? Obviously not.
>>
>> I don't understand the motivation of this quip.
>
> You don't understand that it is offensive to respond to an intelligent
> question by posting a Google query? As a project maintainer you should
> know better.

As a project maintainer I try to foster good exchange of information. I found the link informative. -- Andrei

On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu wrote:
> ... first hit is http://graphicdesign.stackexchange.com/questions/13724/recommended-column-width-for-text-reading-digital-vs-printed pointing to a study indicating 95 characters per line as optimal for on-screen reading comprehension. The subjective preferences, however, was biased toward smaller numbers.
>
> The second link is http://baymard.com/blog/line-length-readability which points to a few studies concluding that 50-75 cpl (characters per line) would be indicated for web design.
>
> Third is http://stackoverflow.com/questions/7460041/whats-a-good-maximum-width-of-text-on-a-webpage which quotes a really nice collection of numbers from Smashing Magazine from popular websites, showing that 84% of the sites they looked at use 65-104 cpl.
>
> It just struck me that Google's own search page that I'm looking at right now, which I vaguely recall did not limit line lengths a few years ago, is now using a 90 cpl limit. The page's right-hand side is a white area.
>
> Next is http://webstyleguide.com/wsg3/7-page-design/6-page-width-line-length.html, which mentions 66 cpl as optimal from a physiological standpoint.
>
> Next is http://socialtriggers.com/perfect-content-width/ which nicely advocates smaller cpl at the top of the content (so people read the essential message quickly) followed by 100 cpl.

Gosh now I finally know what researches to blame for my eyes bleeding upon most web site restylings (Facebook *caugh-caugh*). If anything it just shows that overall reading skills are decreasing and no one care about visitors with small fonts (me). But current HTML/CSS standards don't provide way to express sizes as percentage of screen width (as opposed to page window width), do they?

On 4/23/14, 9:28 AM, Dicebot wrote:
> Gosh now I finally know what researches to blame for my eyes bleeding
> upon most web site restylings (Facebook *caugh-caugh*). If anything it
> just shows that overall reading skills are decreasing and no one care
> about visitors with small fonts (me). But current HTML/CSS standards
> don't provide way to express sizes as percentage of screen width (as
> opposed to page window width), do they?

I don't know. It's a good question and an interesting challenge. -- Andrei

On Wed, Apr 23, 2014 at 04:28:30PM +0000, Dicebot via Digitalmars-d wrote: [...]
> Gosh now I finally know what researches to blame for my eyes bleeding upon most web site restylings (Facebook *caugh-caugh*). If anything it just shows that overall reading skills are decreasing and no one care about visitors with small fonts (me).

On the contrary, I find almost all websites have broken layouts because I enforce a minimal font size of 16pt (I have a high-resolution screen) -- they insist on font sizes that are far too small.  Usually makes me override the site's style with my own custom-made one (or just move on to the next site).


> But current HTML/CSS standards don't provide way to express sizes as percentage of screen width (as opposed to page window width), do they?

They provide sizes per font measurements, which is good enough for implementing CPLs, no?


T

-- 
Time flies like an arrow. Fruit flies like a banana.

On Wednesday, 23 April 2014 at 16:28:32 UTC, Dicebot wrote:
> *caugh-caugh*). If anything it just shows that overall reading skills are decreasing and no one care about visitors with small fonts (me). But current HTML/CSS standards don't provide way to express sizes as percentage of screen width (as opposed to page window width), do they?

Javascript libraries fill this gap: http://simplefocus.com/flowtype/