www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Preprocessing CSS

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Found this on reddit: 
http://blog.00null.net/post/144763147991/using-gnu-m4-as-a-css-pre-processor. 
I found it interesting because I found it useful to preprocess our 
style.css on dlang.org with ddoc. Somehow that got lost a while ago. How 
can I find the rename style.css -> style.css.dd and then back on github? 
Thx! -- Andrei
May 23 2016
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 23-May-2016 19:04, Andrei Alexandrescu wrote:

 Found this on reddit:
 http://blog.00null.net/post/144763147991/using-gnu-m4-as-a-css-pre-processor.
 I found it interesting because I found it useful to preprocess our
 style.css on dlang.org with ddoc. Somehow that got lost a while ago. How
 can I find the rename style.css -> style.css.dd and then back on github?
 Thx! -- Andrei


Or just use SASS or LESS or any popular tool designed for CSS, no?

-- 
Dmitry Olshansky
May 23 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/23/2016 02:15 PM, Dmitry Olshansky wrote:

 On 23-May-2016 19:04, Andrei Alexandrescu wrote:

 Found this on reddit:
 http://blog.00null.net/post/144763147991/using-gnu-m4-as-a-css-pre-processor.

 I found it interesting because I found it useful to preprocess our
 style.css on dlang.org with ddoc. Somehow that got lost a while ago. How
 can I find the rename style.css -> style.css.dd and then back on github?
 Thx! -- Andrei


 Or just use SASS or LESS or any popular tool designed for CSS, no?


I looked into those and they seemed to add additional dependencies for 
little else than what could be done with ddoc immediately. -- Andrei
May 23 2016
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-05-23 22:03, Andrei Alexandrescu wrote:


 I looked into those and they seemed to add additional dependencies for
 little else than what could be done with ddoc immediately. -- Andrei


Sass supports control flow, like if statements, for loops and so on.

-- 
/Jacob Carlborg
May 24 2016
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Tuesday, 24 May 2016 at 07:05:12 UTC, Jacob Carlborg wrote:

 On 2016-05-23 22:03, Andrei Alexandrescu wrote:


 I looked into those and they seemed to add additional 
 dependencies for
 little else than what could be done with ddoc immediately. -- 
 Andrei


 Sass supports control flow, like if statements, for loops and 
 so on.


If you find that your style sheet needs loops, something has gone 
terribly wrong.
May 24 2016
parent reply Jacob Carlborg <doob me.com> writes:
On 2016-05-24 09:49, Vladimir Panteleev wrote:


 If you find that your style sheet needs loops, something has gone
 terribly wrong.


Fair enough. But claiming that Ddoc can do what Sass can, is just plain 
wrong.

-- 
/Jacob Carlborg
May 24 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/24/2016 09:39 AM, Jacob Carlborg wrote:

 On 2016-05-24 09:49, Vladimir Panteleev wrote:


 If you find that your style sheet needs loops, something has gone
 terribly wrong.


 Fair enough. But claiming that Ddoc can do what Sass can, is just plain
 wrong.


Who made that silly claim? Ah, indeed I now see how what I said could be 
construed like that. Allow me to amend:

"I looked into those and they seemed to add additional dependencies for 
little else than what could be done with ddoc immediately."

->

"I looked into those and for our modest needs they seemed to add 
additional dependencies for little else than what could be done with 
ddoc immediately."


Andrei
May 24 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-05-24 19:32, Andrei Alexandrescu wrote:


 Who made that silly claim? Ah, indeed I now see how what I said could be
 construed like that. Allow me to amend:

 "I looked into those and they seemed to add additional dependencies for
 little else than what could be done with ddoc immediately."

 ->

 "I looked into those and for our modest needs they seemed to add
 additional dependencies for little else than what could be done with
 ddoc immediately."


I suspect we would like to add more and more features from Sass. You 
already talked about adding if statements to Ddoc ;)

-- 
/Jacob Carlborg
May 24 2016
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 23-May-2016 23:03, Andrei Alexandrescu wrote:

 On 05/23/2016 02:15 PM, Dmitry Olshansky wrote:

 On 23-May-2016 19:04, Andrei Alexandrescu wrote:

 Found this on reddit:
 http://blog.00null.net/post/144763147991/using-gnu-m4-as-a-css-pre-processor.


 I found it interesting because I found it useful to preprocess our
 style.css on dlang.org with ddoc. Somehow that got lost a while ago. How
 can I find the rename style.css -> style.css.dd and then back on github?
 Thx! -- Andrei


 Or just use SASS or LESS or any popular tool designed for CSS, no?


 I looked into those and they seemed to add additional dependencies for
 little else than what could be done with ddoc immediately. -- Andrei


Designers have no idea what DDoc is and frankly better off never 
learning it. Also using DDoc for CSS is stretching the tool's purpose.

-- 
Dmitry Olshansky
May 24 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/24/2016 03:54 PM, Dmitry Olshansky wrote:

 Designers have no idea what DDoc is and frankly better off never
 learning it. Also using DDoc for CSS is stretching the tool's purpose.


Yah, that's reasonable. I'd choose ddoc over m4 though, the latter is 
very powerful but feels like the wrong kind of power. One question is 
what's the audience for our css files - D engineers with some Web 
knowledge, or Web engineers with some or no D knowledge? Historically 
it's been more of the former, but I suspect going forward we'll have 
more of the latter. -- Andrei
May 24 2016
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/24/2016 05:02 PM, Andrei Alexandrescu wrote:

 On 05/24/2016 03:54 PM, Dmitry Olshansky wrote:

 Designers have no idea what DDoc is and frankly better off never
 learning it. Also using DDoc for CSS is stretching the tool's purpose.


 Yah, that's reasonable. I'd choose ddoc over m4 though, the latter is
 very powerful but feels like the wrong kind of power. One question is
 what's the audience for our css files - D engineers with some Web
 knowledge, or Web engineers with some or no D knowledge? Historically
 it's been more of the former, but I suspect going forward we'll have
 more of the latter. -- Andrei


One other nice article on css: 
https://hacks.mozilla.org/2016/05/css-coding-techniques/ -- Andrei
May 24 2016
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 24 May 2016 at 21:02:48 UTC, Andrei Alexandrescu 
wrote:

 One question is what's the audience for our css files - D 
 engineers with some Web knowledge, or Web engineers with some 
 or no D knowledge?


CSS isn't really *that* hard to use straight up. I wrote one of 
those fancy css nesters/macro expanders/calculator programs 
<http://code.dlang.org/packages/cssexpand> but I don't use it 
that much because complicating the build at all isn't really 
worth it 95% of the time.

The dlang website isn't particularly complicated either. I say 
let's just keep the code simple.
May 24 2016
prev sibling next sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 23 May 2016 at 16:04:14 UTC, Andrei Alexandrescu wrote:

 Found this on reddit: 
 http://blog.00null.net/post/144763147991/using-gnu-m4-as-a-css-pre-processor.
I found it interesting because I found it useful to preprocess our style.css on
dlang.org with ddoc. Somehow that got lost a while ago. How can I find the
rename style.css -> style.css.dd and then back on github? Thx! -- Andrei


There was no style.css.dd, but there was a cssmenu.css.dd. It was 
removed in the last redesign, as it was no longer needed.
May 24 2016
prev sibling next sibling parent reply Gary Willoughby <dev nomad.so> writes:
On Monday, 23 May 2016 at 16:04:14 UTC, Andrei Alexandrescu wrote:

 Found this on reddit: 
 http://blog.00null.net/post/144763147991/using-gnu-m4-as-a-css-pre-processor.
I found it interesting because I found it useful to preprocess our style.css on
dlang.org with ddoc. Somehow that got lost a while ago. How can I find the
rename style.css -> style.css.dd and then back on github? Thx! -- Andrei


I just want to throw out there that we would get more 
contributors to the website were it to use industry standard 
tools. i.e. Sass, Less, etc.
May 24 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/24/2016 10:39 AM, Gary Willoughby wrote:

 On Monday, 23 May 2016 at 16:04:14 UTC, Andrei Alexandrescu wrote:

 Found this on reddit:
 http://blog.00null.net/post/144763147991/using-gnu-m4-as-a-css-pre-processor.
 I found it interesting because I found it useful to preprocess our
 style.css on dlang.org with ddoc. Somehow that got lost a while ago.
 How can I find the rename style.css -> style.css.dd and then back on
 github? Thx! -- Andrei


 I just want to throw out there that we would get more contributors to
 the website were it to use industry standard tools. i.e. Sass, Less, etc.


That'd need to be balanced with dogfooding. -- Andrei
May 24 2016
parent reply Thiez <thiezz gmail.com> writes:
On Tuesday, 24 May 2016 at 17:14:24 UTC, Andrei Alexandrescu 
wrote:

 On 05/24/2016 10:39 AM, Gary Willoughby wrote:

 On Monday, 23 May 2016 at 16:04:14 UTC, Andrei Alexandrescu 
 wrote:

 Found this on reddit:
 http://blog.00null.net/post/144763147991/using-gnu-m4-as-a-css-pre-processor.
 I found it interesting because I found it useful to 
 preprocess our
 style.css on dlang.org with ddoc. Somehow that got lost a 
 while ago.
 How can I find the rename style.css -> style.css.dd and then 
 back on
 github? Thx! -- Andrei


 I just want to throw out there that we would get more 
 contributors to
 the website were it to use industry standard tools. i.e. Sass, 
 Less, etc.


 That'd need to be balanced with dogfooding. -- Andrei


Is ddoc intended to generate css? Do people who have experience 
with css have experience doing this with ddoc? Will experience in 
using ddoc for css generation help someone in projects other than 
D? Does the experience help someone getting a job in the industry?

I'm pretty sure the answer to all of these answers is "no", so 
why is this even being considered? And how does using ddoc for 
css generation even qualify as dogfooding? If D owned a scissors 
factory, would you use those instead of knives when you eat your 
dinner and call it "dogfooding"?
May 24 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/24/2016 02:03 PM, Thiez wrote:

 On Tuesday, 24 May 2016 at 17:14:24 UTC, Andrei Alexandrescu wrote:

 On 05/24/2016 10:39 AM, Gary Willoughby wrote:

 On Monday, 23 May 2016 at 16:04:14 UTC, Andrei Alexandrescu wrote:

 Found this on reddit:
 http://blog.00null.net/post/144763147991/using-gnu-m4-as-a-css-pre-processor.

 I found it interesting because I found it useful to preprocess our
 style.css on dlang.org with ddoc. Somehow that got lost a while ago.
 How can I find the rename style.css -> style.css.dd and then back on
 github? Thx! -- Andrei


 I just want to throw out there that we would get more contributors to
 the website were it to use industry standard tools. i.e. Sass, Less,
 etc.


 That'd need to be balanced with dogfooding. -- Andrei


 Is ddoc intended to generate css?


Yes. Ddoc is a general preprocessing engine, much like m4 discussed in 
the article I mentioned.


 Do people who have experience with css
 have experience doing this with ddoc?


If they're D contributors they're likely familiar with ddoc, and 
applicability to css is trivial and immediate.


 Will experience in using ddoc for
 css generation help someone in projects other than D?


Probably not, but "experience" is misapplied here - we're talking about 
trivial application here.


 Does the
 experience help someone getting a job in the industry?


Probably not, again with the same caveat. I speculate experience with 
one of the other CSS scripting engines would also not be very helpful in 
landing a job as a software engineer.


 I'm pretty sure the answer to all of these answers is "no"


That's not the case, so the jury shall ignore the consequent :o).


Andrei
May 24 2016
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 24 May 2016 at 18:47:57 UTC, Andrei Alexandrescu 
wrote:

 If they're D contributors they're likely familiar with ddoc, 
 and applicability to css is trivial and immediate.


A lot of D authors are at least familiar with it as inline 
documentation, but I haven't seen nearly as many use the 
standalone ddoc generator (the files with Ddoc at the top), and 
of them even fewer have probably used it for css, where the 
syntaxes kinda clash.


 Probably not, again with the same caveat. I speculate 
 experience with one of the other CSS scripting engines would 
 also not be very helpful in landing a job as a software 
 engineer.


There's a lot of job listings for front end engineers that say 
experience with those is preferred.
May 24 2016
prev sibling next sibling parent reply Seb <seb wilzba.ch> writes:
On Tuesday, 24 May 2016 at 18:47:57 UTC, Andrei Alexandrescu 
wrote:

 Is ddoc intended to generate css?


 Yes. Ddoc is a general preprocessing engine, much like m4 
 discussed in the article I mentioned.


I had a very hard time to get used to Ddoc and all the custom D 
macros, but still I think the idea of shipping such a general 
engine with the compiler is great. However we should make it more 
powerful then. Can't we allow CTFE in Ddoc?
This would help a lot!

I have made a couple of improvement's to the dlang.org, but they 
all are JS "post-processing" hacks, because at the moment one 
can't do this in Ddoc
See e.g.

https://github.com/dlang/dlang.org/pull/1288 (adding anchors)
https://github.com/dlang/dlang.org/pull/1307 (showing list of 
contributors)

A lot of other stuff (LaTeX support, search index, grouped 
overview menu etc.) would also be possible then.
May 24 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/24/2016 03:03 PM, Seb wrote:

 On Tuesday, 24 May 2016 at 18:47:57 UTC, Andrei Alexandrescu wrote:

 Is ddoc intended to generate css?


 Yes. Ddoc is a general preprocessing engine, much like m4 discussed in
 the article I mentioned.


 I had a very hard time to get used to Ddoc and all the custom D macros,
 but still I think the idea of shipping such a general engine with the
 compiler is great. However we should make it more powerful then. Can't
 we allow CTFE in Ddoc?
 This would help a lot!


That would be the domain of more advanced formatting engines such as 
ddox. I wanted to get into ddox in the "I'll give myself 15 minutes to 
do this" manner two times - even tried to redo my personal website with 
ddox. I had to give up mostly due to documentation issues and 
installation difficulties, but to my credit - :o) - I did send Sönke a 
detailed email with what happened.


 I have made a couple of improvement's to the dlang.org, but they all are
 JS "post-processing" hacks, because at the moment one can't do this in Ddoc
 See e.g.

 https://github.com/dlang/dlang.org/pull/1288 (adding anchors)
 https://github.com/dlang/dlang.org/pull/1307 (showing list of contributors)

 A lot of other stuff (LaTeX support, search index, grouped overview menu
 etc.) would also be possible then.


Agreed, there's a lot of opportunity there.


Andrei
May 24 2016
prev sibling parent reply sarn <sarn theartofmachinery.com> writes:
On Tuesday, 24 May 2016 at 18:47:57 UTC, Andrei Alexandrescu 
wrote:

 On 05/24/2016 02:03 PM, Thiez wrote:

 Does the
 experience help someone getting a job in the industry?


 Probably not, again with the same caveat. I speculate 
 experience with one of the other CSS scripting engines would 
 also not be very helpful in landing a job as a software 
 engineer.


Not at a big company, but in small companies with maybe three 
engineers, broad skillsets are very much in demand.  Even if 
you're nominally a backend engineer, you can't say, "Sorry, I 
just don't *do* CSS."

On my second-last contract there were about two engineers on the 
project at any time, and I felt like I wrote nearly as much 
JavaScript and (SASS) CSS as Python.

Pulling Ruby in as a dependency for dlang.org would be sucky, but 
anything other than SASS or LESS (or something syntax compatible) 
is going to turn away a lot of contributors.  A homebrew macro 
system would make most run screaming, no matter how easy it is to 
learn.
May 24 2016
next sibling parent Seb <seb wilzba.ch> writes:
On Wednesday, 25 May 2016 at 00:15:48 UTC, sarn wrote:

 Pulling Ruby in as a dependency for dlang.org would be sucky, 
 but anything other than SASS or LESS (or something syntax 
 compatible) is going to turn away a lot of contributors.  A 
 homebrew macro system would make most run screaming, no matter 
 how easy it is to learn.


Isn't there libsass (http://sass-lang.com/libsass) and
https://github.com/sass/sassc?
Shouldn't that make it rather easy to set it up as a dependency 
in the makefile?
Just `git clone` and `make`.
May 24 2016
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Wednesday, 25 May 2016 at 00:15:48 UTC, sarn wrote:

 Pulling Ruby in as a dependency for dlang.org would be sucky, 
 but anything other than SASS or LESS (or something syntax 
 compatible) is going to turn away a lot of contributors.  A 
 homebrew macro system would make most run screaming, no matter 
 how easy it is to learn.


The other side of the coin is that any additional dependency 
added to the build process is going to contribute in turning away 
people who want to contribute to Phobos and just want to see what 
the resulting docs will look like.

DDoc syntax is not that alien in comparison, and is pretty 
self-explanatory. I honestly think there is a lot of exaggeration 
in this thread. Some people complaining in this thread have never 
even contributed anything in the first place!

That said I don't see a lot of demand for preprocessing our CSS 
files at the moment.

And, to add a data point, I have never used (or needed) neither 
SASS or LESS, despite creating a lot of web apps and even working 
at a web design company for a bit. I don't feel like I'm missing 
out.
May 24 2016
parent reply Jacob Carlborg <doob me.com> writes:
On 2016-05-25 05:47, Vladimir Panteleev wrote:


 The other side of the coin is that any additional dependency added to
 the build process is going to contribute in turning away people who want
 to contribute to Phobos and just want to see what the resulting docs
 will look like.


It already turns me away because of Ddoc.


 DDoc syntax is not that alien in comparison


It's very alien.


 and is pretty self-explanatory.


Not really. How do I know which macro to use to create a link to a D 
symbol? There's a bunch to choose from.


 That said I don't see a lot of demand for preprocessing our CSS files at
 the moment.

 And, to add a data point, I have never used (or needed) neither SASS or
 LESS, despite creating a lot of web apps and even working at a web
 design company for a bit. I don't feel like I'm missing out.


What you don't know you don't miss ;)

-- 
/Jacob Carlborg
May 24 2016
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 25 May 2016 08:28:01 +0200
schrieb Jacob Carlborg <doob me.com>:


 On 2016-05-25 05:47, Vladimir Panteleev wrote:

 That said I don't see a lot of demand for preprocessing our CSS
 files at the moment.

 And, to add a data point, I have never used (or needed) neither
 SASS or LESS, despite creating a lot of web apps and even working
 at a web design company for a bit. I don't feel like I'm missing
 out.  


 
 What you don't know you don't miss ;)
 


One nice feature in SASS is color manipulation: You can easily
lighten/darken colors and use constants for colors to easily generate
different color schemes.

Since GTK has switched to CSS, quite some themes use SASS to
easily provide different theme variants:
http://worldofgnome.org/adwaita-gtk-theme-is-now-ported-to-sass/
https://github.com/horst3180/arc-theme
...

OTOH I don't know if you really need these features in web applications.
May 25 2016
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-05-25 09:35, Johannes Pfau wrote:

 Am Wed, 25 May 2016 08:28:01 +0200
 schrieb Jacob Carlborg <doob me.com>:


 On 2016-05-25 05:47, Vladimir Panteleev wrote:

 That said I don't see a lot of demand for preprocessing our CSS
 files at the moment.

 And, to add a data point, I have never used (or needed) neither
 SASS or LESS, despite creating a lot of web apps and even working
 at a web design company for a bit. I don't feel like I'm missing
 out.


 What you don't know you don't miss ;)


 One nice feature in SASS is color manipulation: You can easily
 lighten/darken colors and use constants for colors to easily generate
 different color schemes.

 Since GTK has switched to CSS, quite some themes use SASS to
 easily provide different theme variants:
 http://worldofgnome.org/adwaita-gtk-theme-is-now-ported-to-sass/
 https://github.com/horst3180/arc-theme
 ...

 OTOH I don't know if you really need these features in web applications.


One of my favorite feature is nesting. The following Sass:

nav {
   ul {
     margin: 0;
   }
}

Would be translated to the following CSS:

nav ul {
   margin: 0;
}

-- 
/Jacob Carlborg
May 25 2016
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 25 May 2016 at 07:35:22 UTC, Johannes Pfau wrote:

 One nice feature in SASS is color manipulation: You can easily 
 lighten/darken colors and use constants for colors to easily 
 generate different color schemes.


My cssexpand program does this too... and I actually find it 
isn't as useful in practice than you'd think anyway, since 
designers tend to just pick out their color palettes and don't 
like it when your code uses a whole bunch of variations on their 
choices.

Their palettes tend to be like ten colors (including shades of 
grey) and they don't like you going outside that in my 
experience. At that point, you might as well just write them (you 
can organize a css file to put them all basically in one place) 
or use a simple variable replacement system instead of all the 
color functions.
May 25 2016
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/25/16 2:28 AM, Jacob Carlborg wrote:

 On 2016-05-25 05:47, Vladimir Panteleev wrote:



 and is pretty self-explanatory.


 Not really. How do I know which macro to use to create a link to a D
 symbol? There's a bunch to choose from.


So much this. And where are they defined?

-Steve
May 25 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 25 May 2016 at 12:14:35 UTC, Steven Schveighoffer 
wrote:

 So much this. And where are they defined?


All over the place.

Seriously, many of the Phobos modules define their own custom 
MYREF or SUBREF macros, in addition to the bazillion existing 
XREF and XREF2 and XREF3 and so on and so forth in the *.ddoc 
files.

And yes, it really is *.ddoc - dlang.org.ddoc has some, then they 
are redefined in latex.ddoc and std-ddox.ddoc and there's 
variants of them in std.ddoc.

This is one of the reasons I ditched all this crap and started 
writing my own docs!
May 25 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/25/16 8:22 AM, Adam D. Ruppe wrote:

 On Wednesday, 25 May 2016 at 12:14:35 UTC, Steven Schveighoffer wrote:

 So much this. And where are they defined?


 All over the place.

 Seriously, many of the Phobos modules define their own custom MYREF or
 SUBREF macros, in addition to the bazillion existing XREF and XREF2 and
 XREF3 and so on and so forth in the *.ddoc files.


Yah, consolidating those would be nice. I ran a large consolidation a 
couple years ago but didn't get to everything.


 And yes, it really is *.ddoc - dlang.org.ddoc has some, then they are
 redefined in latex.ddoc and std-ddox.ddoc and there's variants of them
 in std.ddoc.


That's by design. The whole idea here is to use a given macro and have 
latex.ddoc define it a different way than html.ddoc. Did you find macros 
with identical definitions across ddoc files? (Those would be bugs.)


 This is one of the reasons I ditched all this crap and started writing
 my own docs!


Did you consider simply fixing some of that crap?


Andrei
May 25 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 25 May 2016 at 12:53:10 UTC, Andrei Alexandrescu 
wrote:

 Did you consider simply fixing some of that crap?


I did! The result is at dpldocs.info

A few minor changes also went through Phobos too:

https://github.com/dlang/dlang.org/pull/1177
https://github.com/dlang/dlang.org/pull/1184

but the ddoc model just isn't very good to begin with.
May 25 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/25/2016 09:36 AM, Adam D. Ruppe wrote:

 On Wednesday, 25 May 2016 at 12:53:10 UTC, Andrei Alexandrescu wrote:

 Did you consider simply fixing some of that crap?


 I did! The result is at dpldocs.info

 A few minor changes also went through Phobos too:

 https://github.com/dlang/dlang.org/pull/1177
 https://github.com/dlang/dlang.org/pull/1184


This is great, thanks much.


 but the ddoc model just isn't very good to begin with.


Yah, I wouldn't disagree things can be vastly improved. My point there 
is to make sure we distinguish what's trivially fixable (e.g. redundant 
macro definitions) from larger issues. Again, if you find identical 
macros across dd/ddoc files, or redundant macros that do the same thing 
in just slightly different ways, please fix or file. Thanks!


Andrei
May 25 2016
prev sibling parent Wyatt <wyatt.epp gmail.com> writes:
On Tuesday, 24 May 2016 at 18:03:38 UTC, Thiez wrote:

 If D owned a scissors factory, would you use those instead of 
 knives when you eat your dinner and call it "dogfooding"?


Funny enough, scissors work quite well on food.  They're safer 
and faster than knives in many case. ;)

-Wyatt
May 24 2016
prev sibling parent reply Dicebot <public dicebot.lv> writes:
On 05/23/2016 07:04 PM, Andrei Alexandrescu wrote:

 Found this on reddit:
 http://blog.00null.net/post/144763147991/using-gnu-m4-as-a-css-pre-processor.
 I found it interesting because I found it useful to preprocess our
 style.css on dlang.org with ddoc. Somehow that got lost a while ago. How
 can I find the rename style.css -> style.css.dd and then back on github?
 Thx! -- Andrei


DDOC is the single worst thing in D tooling. I wish there was less of
it, not more.
May 24 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-05-24 21:19, Dicebot wrote:


 DDOC is the single worst thing in D tooling. I wish there was less of
 it, not more.


I couldn't agree more.

-- 
/Jacob Carlborg
May 24 2016