On Monday, 21 April 2014 at 18:35:04 UTC, Andrei Alexandrescu wrote:
> On 4/21/14, 8:48 AM, Aleksandar Ruzicic wrote:
>> On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu wrote:
>>> On 4/19/14, 1:02 AM, Aleksandar Ruzicic wrote:
>>>> I'm planning to start working on this as soon as I get approval
>>>> from Walter/Andrei, and as most of people who answered here are agreed
>>>> that redesign would be a good thing I hope they wouldn't oppose..
>>>
>>> Let's do it. Thank you very much! -- Andrei
>>
>> 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?
>
> Ionno. Not an expert, but I'd say the fewer dependencies the better. Add them only if it's onerously hard to get work done without and/or if their payoff is large.

Understood.


>> 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..
>
> I think you should be fine with ddoc macros instead of Sass.
>
>
> Andrei

I'm not sure if it is smart to use simple text macro processing system as a replacement for full-featured DSL such is Sass. And I don't think that some features available (and really useful!) in Sass are even possible with Ddoc. For example branching with @if, composing of various style sets to optimal CSS (Sass has @extend directive for this).
Also, Ddoc can't minify resulting CSS which is something that is considered good practice (serve gzipped minified JS/CSS), so some external tool must be used for that. With node-sass we can get all that and more (i.e. source maps)..

On 4/21/14, 12:38 PM, Aleksandar Ruzicic wrote:
> I'm not sure if it is smart to use simple text macro processing system
> as a replacement for full-featured DSL such is Sass. And I don't think
> that some features available (and really useful!) in Sass are even
> possible with Ddoc. For example branching with @if, composing of various
> style sets to optimal CSS (Sass has @extend directive for this).
> Also, Ddoc can't minify resulting CSS which is something that is
> considered good practice (serve gzipped minified JS/CSS), so some
> external tool must be used for that. With node-sass we can get all that
> and more (i.e. source maps)..

A little searching turned up libsass.org which apparently is the native library that node.js uses for its implementation. So if there's an objection to full node.js (or if vibe.d is used) then perhaps the native library would do.

On Monday, 21 April 2014 at 20:12:31 UTC, David Gileadi wrote:
> On 4/21/14, 12:38 PM, Aleksandar Ruzicic wrote:
>> I'm not sure if it is smart to use simple text macro processing system
>> as a replacement for full-featured DSL such is Sass. And I don't think
>> that some features available (and really useful!) in Sass are even
>> possible with Ddoc. For example branching with @if, composing of various
>> style sets to optimal CSS (Sass has @extend directive for this).
>> Also, Ddoc can't minify resulting CSS which is something that is
>> considered good practice (serve gzipped minified JS/CSS), so some
>> external tool must be used for that. With node-sass we can get all that
>> and more (i.e. source maps)..
>
> A little searching turned up libsass.org which apparently is the native library that node.js uses for its implementation. So if there's an objection to full node.js (or if vibe.d is used) then perhaps the native library would do.

Yep, forgot to mention that libsass (used by node-sass) is cross-platform C library. Thanks!

On Monday, 21 April 2014 at 20:12:31 UTC, David Gileadi wrote:
> On 4/21/14, 12:38 PM, Aleksandar Ruzicic wrote:
>> I'm not sure if it is smart to use simple text macro processing system
>> as a replacement for full-featured DSL such is Sass. And I don't think
>> that some features available (and really useful!) in Sass are even
>> possible with Ddoc. For example branching with @if, composing of various
>> style sets to optimal CSS (Sass has @extend directive for this).
>> Also, Ddoc can't minify resulting CSS which is something that is
>> considered good practice (serve gzipped minified JS/CSS), so some
>> external tool must be used for that. With node-sass we can get all that
>> and more (i.e. source maps)..
>
> A little searching turned up libsass.org which apparently is the native library that node.js uses for its implementation. So if there's an objection to full node.js (or if vibe.d is used) then perhaps the native library would do.

Oh, I forgot to mention that I'm not advocating the use of node.js to serve dlang.org (I'm all for vibe.d route!), just to use node.js packages I'm used to (i.e. gulp[1], gulp-sass[2] and gulp-browserify[3]) that ease me in working with front-end projects.

[1] https://www.npmjs.org/package/gulp
[2] https://www.npmjs.org/package/gulp-sass
[3] https://www.npmjs.org/package/gulp-browserify

On 4/21/14, 12:38 PM, Aleksandar Ruzicic wrote:
> I'm not sure if it is smart to use simple text macro processing system
> as a replacement for full-featured DSL such is Sass. And I don't think
> that some features available (and really useful!) in Sass are even
> possible with Ddoc.

Well you'd be surprised. But the same guideline applies - the tool needs to offer enough payoff to justify the dependency.

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.

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.


Andrei

On Monday, 21 April 2014 at 15:48:45 UTC, Aleksandar Ruzicic wrote:
> On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu wrote:
>> On 4/19/14, 1:02 AM, Aleksandar Ruzicic wrote:
>>> I'm planning to start working on this as soon as I get approval
>>> from Walter/Andrei, and as most of people who answered here are agreed
>>> that redesign would be a good thing I hope they wouldn't oppose..
>>
>> Let's do it. Thank you very much! -- Andrei
>
> 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..

I think it is very important to dogfood here and add any currently missing dependencies as dub packages instead.

On 4/21/2014 8:14 AM, Steven Schveighoffer wrote:
>
> but I think having the font
> grow when the window is expanded is somewhat useful.
>

I don't. Overly-large text is just as hard to read as overly-small text.

In any case, if I want the text bigger/smaller, that's what the zoom/text-size settings are for (unless I'm unlucky enough to be using a mobile browser, which all moronically obey CSS's PUOs. PUO: Not just for badly-authored DVDs anymore. Thanks, W3C asshats!!)

> But I agree with Aleksandar, that having the text in a window expand as
> far as my very-wide monitor will go, is not helpful. Things are hard to
> read when they get too long.
>

Yea, I agree too. Luckily that's what max-width is for...although that really SHOULD'VE been a browser setting/feature, not a per-page CSS feature. But then, the browser developers these days will cram anything and everything into CSS/HTML anymore (except, of course, anything that actually gives the *user* any control over anything :/ )

On Monday, 21 April 2014 at 22:35:32 UTC, Nick Sabalausky wrote:
> setting/feature, not a per-page CSS feature. But then, the browser developers these days will cram anything and everything into CSS/HTML anymore (except, of course, anything that actually gives the *user* any control over anything :/ )

Then again, most users don't even know that there is a search function built into the browser… so they probably don'

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.

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

-- 
/Jacob Carlborg

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.

-- 
/Jacob Carlborg