On Wednesday, 31 July 2013 at 14:14:50 UTC, Vladimir Panteleev wrote:
> On Wednesday, 31 July 2013 at 07:35:34 UTC, Jeff Nowakowski wrote:
>> By the way, the worst idea I've seen is to do hyphenation statically on the server side. How does the server know in advance how wide my browser window is or the text size? It can't. It's the client's job to flow the text.
>
> Both hyphenate.js and hyphenate.d statically insert shy hyphens, which indicate potential line breaks to browsers. They are invisible except when the line is wrapped at their position.
>
> Of course, this still doesn't work correctly in some browsers - very old browsers render all shy hyphens as regular hyphens, and some browsers include the invisible shy hyphen characters when you select and copy text.

Someone in IRC,  Hackerpilot I believe, related how they copied and pasted some code from dlang.org into their editor and random things weren't getting syntax highlighted.  He only noticed what was causing it when he was moving the cursor around and his cursor wouldn't move the same number of arrow key presses he made.

Invisible characters breaking my code is pretty much my greatest nightmare as a programmer.

On Wednesday, 31 July 2013 at 21:50:15 UTC, Brad Anderson wrote:
> Someone in IRC,  Hackerpilot I believe, related how they copied and pasted some code from dlang.org into their editor and random things weren't getting syntax highlighted.  He only noticed what was causing it when he was moving the cursor around and his cursor wouldn't move the same number of arrow key presses he made.
>
> Invisible characters breaking my code is pretty much my greatest nightmare as a programmer.

To clarify: I was updating the syntax highlighting file for Textadept so that it would include the latest list of __traits arguments and so on. I copied and pasted the listing off the site into the lexer file and random things failed to highlight.

On 07/31/2013 10:14 AM, Vladimir Panteleev wrote:
> On Wednesday, 31 July 2013 at 07:35:34 UTC, Jeff Nowakowski wrote:
>> By the way, the worst idea I've seen is to do hyphenation statically
>> on the server side. How does the server know in advance how wide my
>> browser window is or the text size? It can't. It's the client's job to
>> flow the text.
>
> Both hyphenate.js and hyphenate.d statically insert shy hyphens, which
> indicate potential line breaks to browsers. They are invisible except
> when the line is wrapped at their position.

Sorry for the misinformation, and thanks for the correction.

Better late than never (the last couple weeks have been very busy):

On Tuesday, 23 July 2013 at 21:00:08 UTC, Walter Bright wrote:
> 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.

I don't entirely agree with this, although I understand where you're coming from. The cost/benefit of settling this firmly favours the costs, so I'll let it slide.

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

Well, I can't, as I've said a few times, because I was instructed to wait for https://github.com/D-Programming-Language/dlang.org/pull/271 to get merged, which, I'm told, will shorten my workload considerably. I realise, since complaining about it, that you've commented on that PR. Maybe, if I have some time, I'll try to tackle it so that it'll automerge (which is tricky because merges are a moving target).

> http://forum.dlang.org/post/ypcykidvradkrhnobaey@forum.dlang.org
>
> has quite a few responses; more than most threads.

But I'm afraid that's analogous to saying "Whilst it is true that we haven't come around to fix your collapsed roof, we've picked up when you called more often than we have for other customers, so I don't see what you're upset about."

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

My training is in business, not computer science. One learns in business school that the successful companies satisfy the needs of a particular market. When the customers' needs drift from what the business produces - as invariably happens in almost all markets - the business can either adapt to its changing environment or invite competitors to do its job for them.

Therefore, regardless of how irrational your customers are, there is often a benefit to giving them what they want.

On Sunday, 14 July 2013 at 04:56:46 UTC, Val Markovic wrote:

> So, Andrei also mentioned how the community needs to improve the
> dlang.orgsite and make it a first-class priority. It's the point of
> contact for
> newcomers so it's very important we get it right. Since I know a
> thing-or-two about web development, I decided to look into improving the
> site.


Let me put my two cents at this thread, hope it would be useful.

(1) The thread went (from the start) to discussion of technical details, not content discussion, and users are interested in content itself, which, IMHO is not optimally organized.

(2) Flashing and slow responses are annoying but not so crucial (as from my experience), thought somebody waits for up to 7 seconds to load web page - agree, that should be fixed, but again, i do not have such problem or didn't noticed (why?).

(3) dlang.org content organisation:
    (3.1) start page describes the language - very good, but it would be better if it also contains clear links (the big big buttons) to overview, download page, tutorial, documentation;
    (3.2) as were already mentioned the documentation should be extracted to dedicated site (either subdomain or subfolder) mainly to remove unnecessary at this section main site navigation. technically it would be better because documentation for sure have different markup / layout / page structure and probably would have different presentation. As for me I loved http://www.erlang.org/doc/man/edoc.html - clear, navigable, lightweight;
    (3.3) explicit language tutorial section would be great benefit (not doc->book->tutorial), language tour like for go language would be excellent.
    (3.4) explicit getting started page (infrastructure preparing)
    (3.4) are articles part of documentation?

(4) design and appearance:
    (4.1) fixed width layout - more readable, all typesetting books recommends line to be no more then 66 characters long;
    (4.2) scrolling navigation pane is annoying.
    (4.3) more lightweight and readable design: lighter background tones and darker foreground tones (people get used to read black symbols on white paper), thiner or zero borders, more explicit headers.

(5) external and outdated content: there are different d specific content outside dlang.org (i.e. source.org) containing tutorials, articles, source codes that is outdated and doesn't even compile. this mislead newbie, gets him irritated and force to quit learning language. if it is possible this content should be revised and incorporated to dlang.org and removed, because it breaks down all language marketing.

This just my thought that i hope could be useful, cause i'm a visual person type and got easily embarrassed by a lot of content especially when it is not well-formed =)

On Saturday, 10 August 2013 at 17:29:40 UTC, Ruslan Mullakhmetov wrote:
> (2) Flashing and slow responses are annoying but not so crucial (as from my experience), thought somebody waits for up to 7 seconds to load web page - agree, that should be fixed, but again, i do not have such problem or didn't noticed (why?).

This was mitigated somewhat by some updates to hyphenate.js and the Jump To generation that were made.  Now it's just slow.  The larger the page the longer it takes so it's most noticeable on big pages (I used the changelog page for testing because it's huge).

On Saturday, 10 August 2013 at 18:22:53 UTC, Brad Anderson wrote:
> On Saturday, 10 August 2013 at 17:29:40 UTC, Ruslan Mullakhmetov wrote:
>> (2) Flashing and slow responses are annoying but not so crucial (as from my experience), thought somebody waits for up to 7 seconds to load web page - agree, that should be fixed, but again, i do not have such problem or didn't noticed (why?).
>
> This was mitigated somewhat by some updates to hyphenate.js and the Jump To generation that were made.  Now it's just slow.  The larger the page the longer it takes so it's most noticeable on big pages (I used the changelog page for testing because it's huge).

The documentation is still almost unusable for me. If I load a tab to view any documentation (example link: http://dlang.org/phobos/object.html#.RTInfo) it will literally freeze Firefox (26, Nightly, happened with 25 and previous versions as well) completely for 10-20 seconds until it pops up asking if I want to stop hyphenate.js because it's taking too long. I had to block it with Adblock Plus for the documentation to be actually feasible to use. And this is on a fairly high end computer.

On 08/10/2013 04:32 PM, Kapps wrote:
>
> The documentation is still almost unusable for me. If I load a tab to
> view any documentation (example link:
> http://dlang.org/phobos/object.html#.RTInfo) it will literally freeze
> Firefox (26, Nightly, happened with 25 and previous versions as well)
> completely for 10-20 seconds until it pops up asking if I want to stop
> hyphenate.js because it's taking too long. I had to block it with
> Adblock Plus for the documentation to be actually feasible to use. And
> this is on a fairly high end computer.


It's not important that some users find it unusable. What's more important is that users get hyphenation, whether they like it or not.

On Sat, Aug 10, 2013 at 05:59:08PM -0400, Jeff Nowakowski wrote:
> On 08/10/2013 04:32 PM, Kapps wrote:
> >
> >The documentation is still almost unusable for me. If I load a tab to view any documentation (example link: http://dlang.org/phobos/object.html#.RTInfo) it will literally freeze Firefox (26, Nightly, happened with 25 and previous versions as well) completely for 10-20 seconds until it pops up asking if I want to stop hyphenate.js because it's taking too long. I had to block it with Adblock Plus for the documentation to be actually feasible to use. And this is on a fairly high end computer.
> 
> 
> It's not important that some users find it unusable. What's more important is that users get hyphenation, whether they like it or not.

I assume you meant that sarcastically, 'cos this hyphenate.js problem has been plaguing us for how long now, and nobody wants to fix it. :-(

We keep talking about not adding more features to D that don't pull their own weight, but here's hyphenate.js, that causes all sorts of problems that users are endlessly complaining about, yet only provides functionality of marginal value (that hardly anybody even notices, except when it screws up, like hyphenating identifiers where it shouldn't). But everyone who tries to do something about it gets stonewalled.

I guess I'll just continue using dlang.org with JS turned off. *shrug*


T

-- 
Many open minds should be closed for repairs. -- K5 user

On 8/10/2013 6:06 AM, Borden wrote:
> Therefore, regardless of how irrational your customers are, there is often a
> benefit to giving them what they want.

Rarely do all customers want the same thing.