On Tuesday, 22 April 2014 at 06:53:41 UTC, Jacob Carlborg wrote:
> 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 never use css macros-tools, regular template libraries are usually better (e.g. jinja2 allows me to execute python expressions if needed). With current browsers the CSS is getting much more streamlined too and the worst browser bugs require javascript detection anyway so macros don't cut it.

If you use static fallbacks then dynamic CSS calc() expressions are starting to become useful (lacking on Safari 5 and some Android browsers).

For javascript I strongly suggest using the very efficient and typesafe Closure compiler. It has a  good optimizer, dead code elimination and tight minimization. And it requires no install-dependencies since it is available as a REST web service:

http://closure-compiler.appspot.com/home

https://developers.google.com/closure/

Closure type annotations are in comments, so the annotated javascript code runs as regular javascript.

Ola.

On Monday, 21 April 2014 at 15:05:57 UTC, Andrei Alexandrescu wrote:
> Wait, are you advocating for text occupying the entire page width, like a telex band? Aren't text lines difficult to follow from the right side to the continuing left side? -- Andrei

What's problem with entire page width? I don't remember difficulty reading w3c docs or gcc docs or linux man pages even when they occupy the entire page width.

On Monday, 21 April 2014 at 15:15:22 UTC, Aleksandar Ruzicic wrote:
> Yes, there were numerous studies about line length (I don't have any links to back this with but I'm sure that searching for "web typography line length" on google would provide some useful articles). And optimal line length is some 80-90 characters (including the whitespace), I'll try not to cross that boundary much.

This isn't specific to the web.  The typographic rules about line lengths are probably as old as the printing press itself.

It annoys me that tried-and-true typographic best practices are constantly and blatantly ignored by web designers.

Relevant:
http://baymard.com/blog/line-length-readability
http://webtypography.net/toc/

On Tuesday, 22 April 2014 at 11:36:37 UTC, Lars T. Kyllingstad wrote:
> It annoys me that tried-and-true typographic best practices are constantly and blatantly ignored by web designers.

Yeah, well, but the truth is that there is no solid truths because there are many variables: line height, font, display acuity, distance to display, reading patterns, age, words etc.

I remember when I was teaching at web design course and was trying to find solid research (it was for m.sc. students) for design guidelines for screens in general and finding something solid was very difficult.

For instance, people don't read web pages inititally. They scan them. So making the page easily scannable for interesting phrases might be more important than actual reading speed.

For users who are skilled at speed reading you want narrow columns so you have vertical movement (as in scientific papers and newspapers). For older people you want large fonts and high contrast. For high acuity displays you want serifs. It is a big problem that too many web-designers are young and don't take older and handicapped people into consideration.

Btw, I think the single word per frame app Spritz pretty much describes how difficult it is to put down absolute guidlines. I have no problem to follow it at 700wps:

http://www.spritzinc.com/

I like your design. Go forth and make it happen.

On line length, the optimal line length is somewhere between 70 and 110 characters from what I have read. I found one study here which didn't turn up a great observable difference in reading speed or comprehension going from 80 to 110 characters.

http://www.perceptionweb.com/ecvp/ecvp03.pdf (Page 107)

This is a general theme from studies I have seen. Results seem to vary a bit. Something inside that range appears to be good.

I recommend Bootstrap for building sites, as it was worked well at my company. The designer here is a big fan of it, and when a site framework makes him happy, it's got to be pretty good.

As for avoiding the SCSS dependency, I'd say just go for plain CSS. SCSS and other CSS wrapper languages give you some nice features, like templates for cross-browser support or variables, but I don't think they justify the complexity involved in using them. We've been using SCSS at the company I currently work in, and so far all I've gotten out of SCSS is that it takes me longer to go through the feedback loop of making a change to a CSS file and seeing it happen in the browser, due to the milliseconds it takes to compile the CSS file. It's really not worth the trouble.

I'll say it again because it's important, go ahead and implement a new design right away. I look forward to it. Press on with something to avoid a design by committee scenario from emerging.

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).

On Tuesday, 22 April 2014 at 12:21:57 UTC, w0rp wrote:
> and 110 characters from what I have read. I found one study here which didn't turn up a great observable difference in reading speed or comprehension going from 80 to 110 characters.

You can do all the quantitative laboratory experiments in the world, but at the end of the day the only thing that is certain is that people don't approach a web page as if they are participating in a reading contest, and that people are different, have different skills and motivation. So, being able to adapt the page to your own needs is the "right" thing to do.

What is certain is that testing with a heterogeneous group of real people is much more efficient than evaluation by a usability expert, no matter how proficient that expert is. ;-)

On 4/21/14, 11:51 PM, Jacob Carlborg wrote:
> On 21/04/14 23:23, Andrei Alexandrescu wrote:
>
>> I confess getting a bit uncomfortable about adding new dependencies at
>> this point. We depend on dpl-docs already, and the tool was difficult to
>> install and broke from one dmd release to the next. Sönke was nice and
>> proactive about it, but he's an active member of the community. If we
>> find issues with tooling coming from the outside - and we will - we're
>> on our own. It would help if many people in the community are fluent
>> with them.
>
> I've used Sass a lot. Although not via node.

Good to know, thanks.

>> Adding a tool right now that has overlapping functionality with
>> ddoc/dpl-docs, and that is relatively unknown within the community
>> sounds like a tall order.
>
> Sass doesn't overlap with ddoc.

I'm clearly outta my depth here, basing myself off of giving http://sass-lang.com/guide a couple minutes. From what I can tell here's how ddoc matches up sass features:

Pre-processing: yes
Variables: yes
Nesting: no
Partials, Import: somewhat (by passing several ddoc files to dmd)
Mixins: yes
Extend/Inheritance: no
Operators: no

I'm glad to see a revamp of dlang.org happening. Again if the added tools bring great advantages with them, fine. But we can't add dependencies carelessly and only for minor convenience.

Let me ask Aleksandar again: we already depend on dpl-docs since recently. Is it helping/competing with the new tools you plan to add?


Andrei

On 2014-04-22 09:56, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:

> I never use css macros-tools, regular template libraries are usually
> better (e.g. jinja2 allows me to execute python expressions if needed).
> With current browsers the CSS is getting much more streamlined too and
> the worst browser bugs require javascript detection anyway so macros
> don't cut it.

I usually use these languages together with Ruby on Rails. With the assets pipeline in RoR it's possible to pipe several pre-processors together. Erb (Embedded Ruby) -> Sass -> CSS.

-- 
/Jacob Carlborg

On 2014-04-22 14:21, w0rp wrote:
> I like your design. Go forth and make it happen.
>
> On line length, the optimal line length is somewhere between 70 and 110
> characters from what I have read. I found one study here which didn't
> turn up a great observable difference in reading speed or comprehension
> going from 80 to 110 characters.
>
> http://www.perceptionweb.com/ecvp/ecvp03.pdf (Page 107)
>
> This is a general theme from studies I have seen. Results seem to vary a
> bit. Something inside that range appears to be good.
>
> I recommend Bootstrap for building sites, as it was worked well at my
> company. The designer here is a big fan of it, and when a site framework
> makes him happy, it's got to be pretty good.
>
> As for avoiding the SCSS dependency, I'd say just go for plain CSS. SCSS
> and other CSS wrapper languages give you some nice features, like
> templates for cross-browser support or variables, but I don't think they
> justify the complexity involved in using them. We've been using SCSS at
> the company I currently work in, and so far all I've gotten out of SCSS
> is that it takes me longer to go through the feedback loop of making a
> change to a CSS file and seeing it happen in the browser, due to the
> milliseconds it takes to compile the CSS file. It's really not worth the
> trouble.

I say it's the opposite. I never use plain CSS or JavaScript these days. I mostly use Ruby on Rails where this is built-in and has good support. I'm using LiveReload together with Guard. When the Sass/CSS is updated it doesn't even need to reload the whole page, it just updates the stylesheet.

-- 
/Jacob Carlborg