-
-
Notifications
You must be signed in to change notification settings - Fork 379
Remove hyphenate.js #352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove hyphenate.js #352
Conversation
No please. There are many things to improve before we get to remove hyphenation. Removing hyphenation would entail giving up on justified formatting so it would be a net downgrade in readability. |
For a better move: we should upgrade to the latest hyphenator, something we haven't done in a while. Newer releases support CSS3 hyphenation and adds more optimizations: https://code.google.com/p/hyphenator/ |
I already did upgrade hyphenate.js to a version that supports CSS3 (hypenate.js 4.0) about a year ago 4d58b3b. It helped a little bit but it's still slow. I don't see any optimizations in the changelog since the 4.0 release we are using. We should upgrade if we are going to continue using hyphenate.js, of course, but I don't think it will solve the performance problem. |
@eco great, thanks. We're still two releases behind and at least 4.1.0 does add optimizations, see https://code.google.com/p/hyphenator/wiki/en_VersionHistory: faster pattern checking (async), globally hide and unhide text by setting CSS classes (faster). Also there is advice on writing fast pages, see https://code.google.com/p/hyphenator/wiki/en_Optimizations, paragraph starting with "What an webauthor can do: ..." (we don't do that). I'm not sure where we are with sync/async/flicker control for our site, a good start would be go explore different modes of hyphenation. In brief, no problem with removing this if necessary, but there are a bunch of things we could and should do (with hyphenator and orthogonal to it) to improve page speed before removing this valuable functionality. |
IF this feature cost a perceptible performance difference or is the source of shifting content, then I believe that we're making the wrong customer experience trade off here. Hyphenation and text justification are of marginal value, imho. Snappy pages that only render once are of high value. |
Come on guys, there no reason why hypenation for static content has to be done by the client. |
Generated from: http://hyphenator.googlecode.com/svn/tags/Version%204.2.0/mergeAndPack.html Vim apparently has a bug when copying and pasting text from Chrome.
Obviously I'm in favor of this because I opened this pull request. The current state of things after I worked on a compromise is that fast CSS3 hyphens support is now used on every browser but Chrome and Opera. Doing it in a makefile was also what I felt should happen until I read a line in hyphenator's FAQ:
The last thing D needs is making everything harder to search for. The only two options we are left with are no hyphenation on Chrome and Opera or to use hyphenator (we needn't worry about other browsers as the CSS3 hyphens support works great and is very fast in my testing). |
@andralex I disagree that this is "valuable functionality". It's a major time waster on Opera (my main browser), and makes the site hard to use for me. After turning off JS on dlang.org, I found that it is significantly more usable, and suffers from no noticeable degradation in readability. Judging by the repeated complaints about this on the D forum, I'm by far not the only one who is experiencing this. Please reconsider this pull. I agree that if hyphenation is deemed necessary, then it should be done server-side, not client-side. Repeatedly hyphenating static HTML pages on the client-side simply makes no sense. |
I hosted the documentation with disabled hyphenate.js and Just an extreme example. |
Just to be clear, Jan enabled mod_deflate on dlang.org so the only thing On the subject of server configuration, I'm probably going to prepare some |
To back up @dawgfoto 's numbers, I just did a quick test: (1) Clear browser cache, enable JS, reload dlang.org: total load time: 7s. (2) Clear browser cache, disable JS, reload dlang.org: 1.9s. Guess which setting I will be using from now on. |
And another update, running |
No |
The whole listanchors business should be gotten rid of, it's a net negative. Ideas for a better design? |
Restore unicode characters in hyphenate.js
build list anchors as soon as the DOM is ready
Seems like there are four options:
I prefer 4 because it brings more to the table overall and is the least amount of extra work. 1 feels like something Walter wouldn't go for and I don't know if I like either. 2 and 3 just require a dedicated person or two to do the work. |
I strongly favor static generation over dynamic generation when the dynamic generation is identical to the static. The way I'd frame this: what cannot be done at doc build time? (note: not isn't currently.. I mean can't with work being done on the generator). Serving static files is significantly more efficient than any other mechanism. Personally, the order you listed them matches my order of preferences. |
How about going only with css hyphens which are already enabled? http://caniuse.com/css-hyphens |
@dawgfoto +1, use CSS hyphenation if the browser supports it, otherwise just leave it alone. Get rid of JS hyphenation. |
This would be my prefered approach as well. hyphens: auto is already in place so we'd just need to get rid of hyphenator. |
Can you update this pull request then and leave the |
I've rebased it against master and modified it as needed. New commit isn't showing up here though. My guess is Github doesn't bother to resync closed pull requests. I can create a new pull request if necessary. |
Can one of you org members reopen this? |
Thanks for reopening, Jonathan, but GitHub is not picking up the current branch state for some reason. Opened #367 to replace this. |
To trigger an update you need to force push a new commit hash. |
How about using |
Nice. My concern is still that adding ­ throughout the middle of words has an unknown effect on search engine results and rankings. |
While this is a valid concern, I don't think that is an issue for us. Google does correctly ignore soft hyphens so searching on dlang.org will work. Most search engines seem to handle HTML4 correctly. If we decided SEO was important to us we should tackle this thoroughly rather than making decisions based on rumors. Having a look at a SEO report for dlang.org, improving the load time is probably the most rewarding tasks on this list. |
My main point is that hyphenation does not add enough value to risk even a small dip in page ranking and searchability. D is already criticized for (and you just showed yourself) being difficult to search for. So much so that a FAQ entry had to be added to help alleviate the problem. If you can confirm adding ­ everywhere won't hurt search results then I'm all for hyphenation done during page generation. Page source would be a bit ugly but that's not really a major problem. I'm sure Andrei would appreciate it. |
My argumentation went slightly different.
Frankly the documentation is currently a pain. NB: |
I just think the overall visibility of D on search engines matters. A higher pagerank means someone searching for "alternative to C++" is more likely to find D and that's the sort of thing that is important. Reference lookup searches are not all that important as you've said. I think you are probably right that ­ doesn't affect page ranking though. I think we are in complete agreement about the course of action. I was going to send some apache configuration to Jan to get proper caching of the site but a CDN would be even better. |
I know Andrei is passionate about hyphenation but the current client-side javascript hyphenation slows down the website significantly for all users. If hyphenation is desired it should be done during page generation.Replaced by #367