On Tuesday, 23 July 2013 at 14:48:11 UTC, H. S. Teoh wrote:
> Seriously, we need to take a deep breath, step back, and
> get the right perspective on things. Hyphenation is mostly a
> *non-issue*. Most people don't even notice it!

Here is yet another point of view - hyphenation makes text ugly and more difficult to read ;) For me it is a pure legacy of hand-written texts where it sometimes hard to reason if word will fit into the remainder of the line.

On Tuesday, 23 July 2013 at 14:56:46 UTC, Dicebot wrote:
> Here is yet another point of view - hyphenation makes text ugly and more difficult to read

It certainly looks strange as it's unusual for the web.

On 2013-07-23 15:19, Dicebot wrote:

> There is nothing here D can't do. Dogfooding ftw.

I give up, there's obviously no point in arguing.

-- 
/Jacob Carlborg

23-Jul-2013 18:46, H. S. Teoh пишет:
> On Tue, Jul 23, 2013 at 09:47:02AM +0200, nazriel wrote:
> [...]
>> Hyphenate.js indeed has an impact on load times and removing it
>> in favor of CSS3 would fix the problem. Of course there is
>> probability that people with '90s browsers will complain (stares
>> at Nick ;>) but it is their choice to stick with such outdated
>> software.
> [...]
>
> Honestly, I think hyphenation is blown wayyyy out of proportion. I
> turned off JS on dlang.org (I use Opera) because it was so slow, and now
> the site is significantly faster. And guess what? I didn't even *notice*
> the lack of hyphenation until I saw threads about the slowness of
> hyphenate.js. Seriously, we need to take a deep breath, step back, and
> get the right perspective on things. Hyphenation is mostly a
> *non-issue*. Most people don't even notice it! Have you ever seen
> threads on the forum about why dlang.org sucks because it lacks
> hyphenation? I haven't. So why are we paying such a hefty tax on it
> (i.e. hyphenate.js's slow performance)? On the contrary, there are tons
> of threads about slow loading times.

Aside from that numerous issue coming up in the past along the line of "hyphenated the wrong thing" namely function names in tables and whatnot. It was a burden and it's a burden still.

> So I say, leave the CSS3 hyphenation stuff in, so that whoever uses
> browsers that support it will get the benefit, and take out
> hyphenate.js, because the ROI is simply too small to justify such a big
> performance hit.

+1

-- 
Dmitry Olshansky

On 7/23/2013 2:23 AM, Borden wrote:
> On Sunday, 14 July 2013 at 20:35:45 UTC, Walter Bright wrote:
>>
>> 3. HTML, PDF, Ebook, and CHM outputs are generated from Ddoc.
>
> Walter, with respect, I know you're too smart to be saying something silly like
> this. Surely you know that ebooks and CHM are specially-compiled HTML files. To
> imply that DDoc, and not HTML, is the common denominator between these outputs
> brings me to the acme of frustration as I have said over and over again that, at
> the very least, ebooks depend upon good HTML output.

It's true that they are based on HTML output. However, and this is a big however, they need significantly different HTML output than one puts on a web site. This is currently accomplished by changing the macro definitions that Ddoc uses, and by carefully recoding the Ddoc source to use those macros. While generating ebooks is often billed as "just pipe your website HTML through our converter program!" the reality is that you'll get more or less utter garbage if you try that.

I've published several ebooks that also exist as web pages, so I'm familiar with the process.

> To this end, I have tried for months to help bring dlang.org up to HTML 5
> standard if, for no other end, to be able to compile the spec into an epub
> format. I even toed the github waters by submitting a trivially simple PR which,
> for the past months, has gone completely ignored.

I assume this one is it?

https://github.com/D-Programming-Language/dlang.org/pull/320

I posted a response. (But in general, PR's that are flagged as "We can’t automatically merge this pull request" tend to not get much attention. Despite that, we can and should do better.)

Can you please make some PR's which illustrate your work in converting it to HTML 5?


> In the meantime, my offers on help with other dlang.org PRs have also gone
> ignored. The thread in which I keep offering to help (Dlang spec rewrite) has
> gone ignored. To argue that contributions are not languishing or that volunteers
> are not being ignored necessarily means that I do not exist.

http://forum.dlang.org/post/ypcykidvradkrhnobaey@forum.dlang.org

has quite a few responses; more than most threads.


> If I have learnt one thing in the past few months, it is that any attempt to
> dispute using DDoc to program an entire website is a fool's exercise. Despite
> vocal objections from the plebian masses, the DDoc architects and maintainers
> will stubbornly defend its usefulness. One can hardly blame them: wouldn't any
> of us defend code that we had carefully designed or write?
>
> Therefore, dlang.org will stay, for better or worse, in DDoc. It's not worth
> arguing. As for willing contributors, it seems to me that the maintainers have
> an agenda to which they are adhering. Contributions focussed on other areas are
> diversions.

Of course we have an agenda :-)

The arguments were (I thought) well laid out in that thread and responded to. Reasonable people can disagree - it doesn't mean that one side is irrational.

On Tuesday, 23 July 2013 at 21:00:08 UTC, Walter Bright wrote:
> But in general, PR's that are flagged as "We can’t automatically merge this pull request" tend to not get much attention. Despite that, we can and should do better.

Only committers see that notice. Contributors who do not have commit access do not see that notice. If you need a pull request author to update their pull request, you need to let them know explicitly.

On 7/23/2013 4:57 PM, Vladimir Panteleev wrote:
> On Tuesday, 23 July 2013 at 21:00:08 UTC, Walter Bright wrote:
>> But in general, PR's that are flagged as "We can’t automatically merge this
>> pull request" tend to not get much attention. Despite that, we can and should
>> do better.
>
> Only committers see that notice. Contributors who do not have commit access do
> not see that notice. If you need a pull request author to update their pull
> request, you need to let them know explicitly.

Ah, I had no idea that was true. Thanks for letting me know!

On Tuesday, July 23, 2013 17:42:30 Walter Bright wrote:
> On 7/23/2013 4:57 PM, Vladimir Panteleev wrote:
> > On Tuesday, 23 July 2013 at 21:00:08 UTC, Walter Bright wrote:
> >> But in general, PR's that are flagged as "We can’t automatically merge
> >> this
> >> pull request" tend to not get much attention. Despite that, we can and
> >> should do better.
> > 
> > Only committers see that notice. Contributors who do not have commit access do not see that notice. If you need a pull request author to update their pull request, you need to let them know explicitly.
> 
> Ah, I had no idea that was true. Thanks for letting me know!

Agreed. I didn't realize that that was the case either. Thanks Vladimir!

- Jonathan M Davis

On 2013-07-24 01:57, Vladimir Panteleev wrote:

> Only committers see that notice. Contributors who do not have commit
> access do not see that notice. If you need a pull request author to
> update their pull request, you need to let them know explicitly.

I thought I he was referring to the auto tester? Anyway, the auto tester will indicate if the merge failed. Or if it failed to compile, run and run the tests.

-- 
/Jacob Carlborg

On Wednesday, 24 July 2013 at 06:44:25 UTC, Jacob Carlborg wrote:
> On 2013-07-24 01:57, Vladimir Panteleev wrote:
>
>> Only committers see that notice. Contributors who do not have commit
>> access do not see that notice. If you need a pull request author to
>> update their pull request, you need to let them know explicitly.
>
> I thought I he was referring to the auto tester? Anyway, the auto tester will indicate if the merge failed. Or if it failed to compile, run and run the tests.

This does not apply to the dlang.org repo, which is not being tested.