April 22, 2014
On 2014-04-22 18:38, Andrei Alexandrescu wrote:

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

I'm not going to argue which is best. But since I started to use Sass, I see no reason to use plain CSS. Even just for nesting, which is the most used feature I've seen people use, I think it's worth it. Although, I'm using Ruby on Rails which comes bundled with Sass.

-- 
/Jacob Carlborg
April 22, 2014
On 4/22/14, 3:32 AM, Kagamin wrote:
> 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.

https://www.google.com/search?q=page%20width%20study#q=optimal+page+width+for+reading&safe=off

Andrei
April 22, 2014
On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu wrote:
> On 4/22/14, 3:32 AM, Kagamin wrote:
>>
>> 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.
>
> https://www.google.com/search?q=page%20width%20study#q=optimal+page+width+for+reading&safe=off
>

As I have already pointed out, there is no optimal width. E.g. if you have 3 lines per paragraph you can have longer lines. If you have 20 lines per paragrap you need shorter ones. So why are you doing this? Trying to be clever? Obviously not.

Kagamin meant "window width". Clearly if the user can adjust his window he can get the desired text width. Only after two decades of academics pointing out a need for flexible width do web designers get it and start chanting for "responsive design". Not because they actually understand what they are doing, but because they were FORCED to leave their ugly fixed width obsession by the introduction of mobile devices.

Too many documentation sites still get this wrong, meaning: they don't work properly if the user sets a larger font or uses his own stylesheets.

This is the proper link:

http://www.w3.org/TR/WCAG20-TECHS/

(You ARE flame baiting, right? I think you owe Kagamin an apology.)
April 22, 2014
On 4/22/2014 4:39 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>
> This is the proper link:
>
> http://www.w3.org/TR/WCAG20-TECHS/
>

Man do I REALLY wish movie makers and game devs would at least TRY to follow this one:

http://www.w3.org/TR/WCAG20-TECHS/G56.html

In just the last decade, it's become absurdly common for dialog to be *quieter* than sound effects and background music. Insane.

April 22, 2014
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..
April 22, 2014
On Tuesday, 22 April 2014 at 16:38:04 UTC, Andrei Alexandrescu wrote:
> 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

It's not competing with Sass. Sass would make it easier for me to faster write needed styling and also more importantly to have style files easy to maintain later (I had worked few times with monolithic 3000+ lines long CSS files and can attest that it's much easier to work with nice hierarchy of small SCSS files).

I can surely do without Sass and use plain CSS but to keep it maintainable I would need to split it to multiple files and would need a tool to concat those later to the target CSS (this can be done with cat but it's non-standard on windows) and then I would need a tool to minify that CSS.

These are simple tools, and they can be written from scratch in D (which I would like to do, but then I won't be working on redesign while those are done).

If I would use Sass, I would not only get really nice and powerful DSL to write styles in but I would get tools to concat and minify CSS.

As I've said in message to Dicebot I would not use npm as it would be bad marketing, but I would really like to use libsass (sassc - the compiler, to be precise, libsass is a library used by sassc) which written in C.

If that's too much dependencies I'll have to go with plain CSS files.

And I've already decided to use Make instead of gulp (a npm packaged build tool for node.js).

The only thing that remains is JavaScript minifyer. I have tried almost all of them, Google Closure Compiler, YUICompressor, jsmin, UglifyJS and in my experience UgifyJS[1] is definitely the best tool for that task (closure compiler can get your slimmer files but you must stick to Google's rules of writing and annotating your code, which I find too limiting).

The only problem with UglifyJS is that it's a Node.js library/tool...
So I don't know what to do about that. Sure, there are online versions of both Closure Compiler and UglifyJS but they cannot be integrated in build system (well, not without requirement of internet connection).

I wonder if DMDScript's parser could be used to write JS minifier in D. This is actually something I would really like to look into but there is definitely not small amount of work needed to develop a tool like that. So it will have to wait, sadly.

So, as I'm not aware of any native good JS minifing tool I'd skip that step for now. We can optimize that later (anyway, I'll keep JS usage on bare minimum).

The only question yet remaining is if I can depend on sassc[2] or not?


[1] https://github.com/mishoo/UglifyJS
[2] https://github.com/hcatlin/sassc
April 22, 2014
On Tuesday, 22 April 2014 at 19:34:08 UTC, Jacob Carlborg wrote:
> On 2014-04-22 18:38, Andrei Alexandrescu wrote:
>
>> 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.
>
> I'm not going to argue which is best. But since I started to use Sass, I see no reason to use plain CSS. Even just for nesting, which is the most used feature I've seen people use, I think it's worth it. Although, I'm using Ruby on Rails which comes bundled with Sass.

I'm no Rails (or Ruby) developer but I use Sass for all my
styling needs for a long time now. It was the only reason I had
ruby installation on my computer (nowdays I use libsass, so no
ruby.. yey).

I find it really easy to setup and use thanks to npm and
node-sass package (I prefer not to manually compile my tools),
and build tools like grunt and (now more popular) gulp really
make the life easier for front-end projects (which I still have
to do every once in a while). I just hope we will have such
ecosystem one day in D (with help of gulp).
April 22, 2014
> I have also tried to design something myself (although I'm not a
> designer) and this is what I came up with:
>
> http://krcko.net/dlang.org/dlang-home-draft1.png
>
> I'm not entirely satisfied with it but I believe that it looks better
> (or at least more modern) than the current design.
>
This looks great, finally something that doesn't scare off people.
Please let me know if you need any help to make this happen.

April 22, 2014
On 04/21/2014 05:48 PM, Aleksandar Ruzicic wrote:
> Just one question, would it be okay to depend on node.js/npm to manage
> dependencies (i.e. CSS/JS frameworks) and build CSS/JS files?
>
> As I'd use Sass for styling, which must be translated to CSS (I'd use
> node-sass package witch doesn't require ruby), and browserify to have
> Common-JS modules..

Why do you want to write the whole CSS yourself? Isn't something like bootstrap more appropriate for the task?
April 22, 2014
On 4/22/2014 6:26 PM, Martin Nowak wrote:
> On 04/21/2014 05:48 PM, Aleksandar Ruzicic wrote:
>> Just one question, would it be okay to depend on node.js/npm to manage
>> dependencies (i.e. CSS/JS frameworks) and build CSS/JS files?
>>
>> As I'd use Sass for styling, which must be translated to CSS (I'd use
>> node-sass package witch doesn't require ruby), and browserify to have
>> Common-JS modules..
>
> Why do you want to write the whole CSS yourself? Isn't something like
> bootstrap more appropriate for the task?

Apparently they can't even manage make basic links work properly:

http://getbootstrap.com/examples/starter-template/

How anyone can manage to fuck up <a href="...">...</a> is beyond me.