When I go to reply to a post, the textbox is absurdly tiny, and since it's no longer a browser textarea, it can't be resized using browser controls. It's basically unusable.
Also I'm not contributing an article when making this post. I am creating a new thread.
Jump to PostIt's actually not just the spell checker. The editor we're using now has a decent API that lets us do things like have the code button work the way it does. Essentially, it's not just code highlighting vs spell check. It's properly formatted code vs spell check. You guys have …
Jump to PostThe only time I look at it is when I post a link and can't remember which bit holds the url and which bit holds the label.
Hit Ctrl+L to insert a link. Much easier that way. :)
Jump to PostI've been getting that one too on Chrome 19/Windows 7 64-bit. Note that it was present before you put my Markdown changes in place, so no worries that the recent update introduced that particular bug. ;)
It seems to be a rezising issue, but I haven't yet encountered it on …
Jump to PostI have seen this on FF12
Jump to PostAs mentioned in another thread, I'm able to duplicate the cursor offset bug, as we're calling it, and have been working to track down a solution to very little avail. But we're aware and it's our #1 priority right now.
How big do you need the reply textbox to be? I've got really crappy eyesight these days (long story) but find the textbox to be perfectly adequate here to be honest. I'm not sure how it could be described as unusable, unless you are seeing something entirely different to me. Plus, it expands dynamically as you use it so gets bigger the more you type.
The articles vs posts vs threads vs news stories vs tutorials thing is just a matter of semantics. You may think you are starting a new thread but actually you are contributing an article whether you like it or not, because that's what DaniWeb calls them now :)
It is a bit on the small side IMO. I can imagine people missing it completely
I'm looking at DaniWeb on a 22" screen at a res of 1920x1080 with IE9 not quite maximised, but with text size increased courtesy of my low vision. The reply textbox stretches across approx half of the screen and appears, fairly logically it seems to me, at the bottom of the thread I'm reading. Which is why I'm bemused by the 'too small' remarks. It makes me wonder it it appears very differently indeed for other users - how much screen estate does it occupy for you Nick, Rash?
The editor resizes as you edit your post. I've found that it's not perfect and you may end up scrolling a bit in some cases, but it does at least attempt grow and shrink to fit the content.
The editor looks ok to me. The only problem I have with it is that confusing instant preview, makes me think I have double vision problems :)
The reply textbox stretches across approx half of the screen
Yes, and that is exactly the problem. Why isn't it as wide as the posts in a thread? On my 2x22" it looks great. On my 10" dell not so much.
The editor resizes as you edit your post
True, but why is it only about 2-3 lines high to begin with? Why not 8-10 lines for example? It would give the replybox a more prominent appearance and would encourage visitors to reply IMO.
The only problem I have with it is that confusing instant preview, makes me think I have double vision problems :)
I'm thinking that the live preview is good, but not when the editor has the same look and feel. I'm always clicking on the live preview to edit my posts instead of the editor. :P But Dani is against raw unhighlighted Markdown in the editor and a live preview with the end result, because that defeats the purpose of the editor we're using, which was chosen for its highlighting features in lieu of spell checking.
Why isn't it as wide as the posts in a thread?
Probably something to do with difficulties in dynamically resizing the editor to match the post div. I honestly don't know why it's that way, but we can certainly look into making the editor and live preview adjust according to your screen width.
True, but why is it only about 2-3 lines high to begin with? Why not 8-10 lines for example?
I'm not sure. There might be a user interface design reason, or maybe too large of a box was distracting if you didn't want to post, or too large of a box could have hidden the live preview such that it wasn't used. That's more of a Dani question since she's the gatekeeper for the UI design. ;)
On my 10" dell not so much
Oddly, on my iPad the reply text box is enormous! Takes up about 70% of the screen width.
I do miss the spellcheck, especially as I have trouble seeing what I've typed half the time these days. A nice squiggly underline works wonders, but my browser add-on spoil chicken sadly doesn't work with the reply textbook. See! That should have been textbox but I didn't spot it until now. Oops :)
I also mis the smilies -- will we ever get them back?
It's actually not just the spell checker. The editor we're using now has a decent API that lets us do things like have the code button work the way it does. Essentially, it's not just code highlighting vs spell check. It's properly formatted code vs spell check. You guys have to admit that the number of poorly formatted code is certainly less than it used to be, which couldn't be accomplished without our current editor.
The smilies are on the todo list. It's not a lack of the ability to do them. It's merely a lack of my regex skills.
I think the code tagging is much better. SPell chechink isn't too important IMO. Smilies - I used to use them, but replies look a lot sleeker without them.
The live preview I could live without. The only time I look at it is when I post a link and can't remember which bit holds the url and which bit holds the label.
The editor is basically broken. For example as I type this text, it blah blah blah hold on, I'm padding out the text a bit so that it spans multiple lines. Let's see what happens. And so we get some more padding to the reply. And some more padding. Anoethuo thue toeh utohe tuho etuh ontehu ontehu onh ontehu santheou sntoheu sntahu ontehu ntoehu ntoehu ntoehoe uontheu ontehu ontehu ntoeh untoeh unto heuntohe ntuho entuho entuho entuho entuh ontehu. Okay. At this point the text box is rapidly alternating between sizes, getting larger and smaller as each character gets written. And then it stops, and a little later happens again, like around the beginning of this sentence.
Press Enter and you get a scrollbar, then press Enter again and it's gone.
Here is some code. Now the whole page scrolled while I started typing code.
Now we're done with the code. And some more testing..
And now that I've accidentally inserted some quoted text and removed it, the text box is much smaller than it used to be and now has a scroll bar. It is only several lines high. This is the narrowness I witnessed previously.
I have no clue what you're trying to explain. Can you provide a screenshot?
The only time I look at it is when I post a link and can't remember which bit holds the url and which bit holds the label.
Hit Ctrl+L to insert a link. Much easier that way. :)
More to do with when i want to edit alink that has the same label and url.
If it has the same label and URL, just type it out and it will autolink.
When you use the link button. You get the url in both url and label. It's remembering which is the url and which is the label that confuses me. So looking at the live preview tells me if I'm editing the right bit. Seriously no big deal - just stating that this is the only time that I find the live preview to be of any use.
Let me type some more text into the editor as another test. I haven't experienced the problems lately so maybe they have magically been fixed, or maybe a browser update changed some wonky behavior. Today Daniweb actually managed to crash Firefox, so there's that. What if I type faster? Blah blah blah blah blah balh balahahaaa
^ right after I typed that last "a", there was a scrollbar, and the cursor was on the subsequent line, in a weird tabbed position
Okay, while writing that last sentence, I got another weird scrollbar situation, and got a screenshot: http://i.imgur.com/IkaGU.png
The cursor is shown there out in the middle of nowhere, on a line that doesn't have any spaces or tabs on it.
What browser/OS, Rash?
I've been getting that one too on Chrome 19/Windows 7 64-bit. Note that it was present before you put my Markdown changes in place, so no worries that the recent update introduced that particular bug. ;)
It seems to be a rezising issue, but I haven't yet encountered it on Chrome 20-beta/Windows 7 32-bit. I also haven't been using Firefox, IE, or Safari often enough for serious posting to see it there either.
Yeah, so my post is really just to say that I've gotten it too, but it wasn't caused by the recent Markdown mode changes. :D
I have seen this on FF12
What browser/OS, Rash?
Firefox 13.0.1, Windows 7.
As mentioned in another thread, I'm able to duplicate the cursor offset bug, as we're calling it, and have been working to track down a solution to very little avail. But we're aware and it's our #1 priority right now.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.
