Permlink Replies: 74 - Pages: 5 [ Previous | 1 2 3 4 5 | Next ] - Last Post: 20-Jul-2020 00:30 Last Post By: RobM Threads: [ Previous | Next ]
JeffTucker

Posts: 6,883
Registered: 31-Jan-2006
Re: jAlbum 21 beta for testing
Posted: 16-Jul-2020 12:32   in response to: AndreWolff in response to: AndreWolff
  Click to reply to this thread Reply
AndreWolff wrote:
You can prevent this....

No, I am not going down that road. I shouldn't need to prevent this. The jAlbum core should not be planting tags into text that conflict with the CSS generated by the skin settings. I am not going to spend my time working to undo the damage.

If a user just wants to italicize or bold a few words, let him learn some very basic code. Using <i> and <b> is not difficult. The more adventurous can learn how to use a simple style attribute to change the color of some text.

Changing the size of text within a line is problematic in many skins, and shouldn't be allowed. And doing it by applying tags like <h1>, <h2>, etc., is completely wrong-headed. Those tags don't have a consistent definition - in one skin, an <h3> might be 24px, but in another skin, it might be 32px. And in another skin, it might be ignored completely.

This "feature" doesn't need to be "worked around." It needs to be removed.
JeffTucker

Posts: 6,883
Registered: 31-Jan-2006
Re: jAlbum 21 beta for testing
Posted: 16-Jul-2020 12:38   in response to: RobM in response to: RobM
  Click to reply to this thread Reply
RobM wrote:
It should at least be enabled/disabled as a skin property setting. Then the bundled skins can support it and third party developers can choose to, or not.

The problem is that the bad coding is applied to the existing title and comment. There's no reliable way to strip it out once it's in there. That's why I referred to this as a "trap door" - once you've gone through the door, there's no way back. The damage is done, and the only way to undo it is for the user to manually remove the stuff. If he knows enough to be able to do that, then he doesn't need this "feature" in the first place.

Yes, you could shut off access to the HTML editor if you've chosen Skin X, but a user can trigger this mangled stuff in his titles and comments while using Skin Y, then change to Skin X. Too late - the garbage is already in there.
AndreWolff

Posts: 1,766
Registered: 14-Dec-2007
Re: jAlbum 21 beta for testing
Posted: 16-Jul-2020 14:27   in response to: JeffTucker in response to: JeffTucker
  Click to reply to this thread Reply
jGromit wrote:
AndreWolff wrote:
You can prevent this....

No, I am not going down that road.

Well I used that function already long before the html editor was introduced, because some users like myself liked to use html code in a description.

But never mind, I only tried to help you.
JeffTucker

Posts: 6,883
Registered: 31-Jan-2006
Re: jAlbum 21 beta for testing
Posted: 16-Jul-2020 14:31   in response to: AndreWolff in response to: AndreWolff
  Click to reply to this thread Reply
Sorry, but I guess I don't understand the purpose of your code. In my skins, I replace the newlines with HTML break tags, so that what the user sees in the album is exactly like what he entered for his title or comment. Works just fine.

I process virtually all user-entered Strings with the same "cleanup" method:
private String cleanString(String s) {
	if(s == null || s.trim().equals("")) return null;
	s = engine.processTemplate(s).replaceAll(" +", " ").replaceAll("\r\n|\r|\n","<br>").replaceAll("<br>$", "").trim();
	if(s.equals("")) return null;
	return s;
}
My point, however, is that we (skin developers) should not have to start "fixing" things that the new HTML editor has created.
AndreWolff

Posts: 1,766
Registered: 14-Dec-2007
Re: jAlbum 21 beta for testing
Posted: 16-Jul-2020 14:41   in response to: JeffTucker in response to: JeffTucker
  Click to reply to this thread Reply
jGromit wrote:
Sorry, but I guess I don't understand the purpose of your code.
If the user did already use html tags I assume that he did replace the new line characters by corresponding html code, so only if no html code is found the new line characters are replaced by <br>, but this solves also the html editor problem.

But on the other hand, David should not replace new line codes if there are already html tags in the description, in which case the problem is also solved.
RobM

Posts: 3,231
Registered: 4-Aug-2006
Re: jAlbum 21 beta for testing
Posted: 16-Jul-2020 14:58   in response to: AndreWolff in response to: AndreWolff
  Click to reply to this thread Reply
AndreWolff wrote:
If the user did already use html tags I assume that he did replace the new line characters by corresponding html code, so only if no html code is found the new line characters are replaced by <br>, but this solves also rhe html editor problem.

But on the other hand, David should not replace new line codes if there are already html tags in the description, in which case the problem is also solved.

Making assumptions is not really a good idea. Many users might include a link tag, but not bother entering break tags, as a newline is quicker and most skins replace them with breaks. Plus it is easier just to do a replace all regardless of the actual content. It’s up to you though.
AndreWolff

Posts: 1,766
Registered: 14-Dec-2007
Re: jAlbum 21 beta for testing
Posted: 16-Jul-2020 15:07   in response to: RobM in response to: RobM
  Click to reply to this thread Reply
Making assumptions is not really a good idea. Many users might include a link tag, but not bother entering break tags
My users don’t need to have html knowledge to enter links, because I use the Github convention link text(link url) to process links (brackets around link text).
RobM

Posts: 3,231
Registered: 4-Aug-2006
Re: jAlbum 21 beta for testing
Posted: 16-Jul-2020 15:24   in response to: AndreWolff in response to: AndreWolff
  Click to reply to this thread Reply
AndreWolff wrote:
Making assumptions is not really a good idea. Many users might include a link tag, but not bother entering break tags
My users don’t need to have html knowledge to enter links, because I use the Github convention link text(link url) to process links (brackets around link text).
I should have said ‘for example a link’, as you have read it literally. So, say the have used italic, bold or any other valid tag that has to be closed.

No reply required.
JeffTucker

Posts: 6,883
Registered: 31-Jan-2006
Re: jAlbum 21 beta for testing
Posted: 16-Jul-2020 15:28   in response to: RobM in response to: RobM
  Click to reply to this thread Reply
RobM wrote:
Making assumptions is not really a good idea.

This is the heart of the problem. When the skin encounters a comment that has embedded HTML tags, it has no way of knowing whether they are the product of a knowledgeable user who is doing something fancy (think of a MarkusD, for example), or whether it's the result of some unwanted stuff from the HTML editor that will just make a mess of things.

So, the skin can't just strip it all out to avoid the problems. If it were that simple, I'd have no difficulty with it - I'm already doing that to all text strings that get used as tooltips, since tooltips in a browser don't honor any HTML tags or styling. I wouldn't need to write some new method - I've got it already!
davidekholm

Posts: 3,222
Registered: 18-Oct-2002
Re: jAlbum 21 beta for testing
Posted: 17-Jul-2020 12:48   in response to: JeffTucker in response to: JeffTucker
  Click to reply to this thread Reply
Sorry to see you so fired up about this addition jGromit :-(. This editor will naturally make styling of descriptions more accessible to a wider user range, for good and bad. Nothing prevents you from stripping out the html tags if you feel they disrupt your skin. I'm also open to allowing skins to control what tags to allow. As nothing has prevented users from entering tags manually, we've always had the potential problem of tags clashing with skin design. Now we make it easier to produce some clashes, true, but we also make it harder to produce invalid html.

If you're particularly worried about a particular button in the editor (say indentation), then we might remove it. I've tried to give skin developers as much control as possible by referring to styles. If you for instance don't want end users to play with indentation in your skin, just override the indentation style with empty code in your common.css.

Sidenote: You can customize the editor's buttons and behavior by editing system/editor.html and pass your suggested modification to me. The makers of the editor provides very good documentation on this.
JeffTucker

Posts: 6,883
Registered: 31-Jan-2006
Re: jAlbum 21 beta for testing
Posted: 17-Jul-2020 14:11   in response to: davidekholm in response to: davidekholm
  Click to reply to this thread Reply
davidekholm wrote:
This editor will naturally make styling of descriptions more accessible to a wider user range, for good and bad.

No, it will make users think that they can apply various types of styling. But most of the resulting code will produce inconsistent, unpredictable results when used in various skins. They will then wonder why the styling isn't working. This has "buggy" built in. It's guaranteed to be unsatisfactory, from the very outset.

Nothing prevents you from stripping out the html tags if you feel they disrupt your skin.

As I've explained, I can't do that. Knowledgeable users may enter their own styling code. I can't tell the difference between what the editor is creating, and what a user is creating. There's no way to reliably separate them.

Beyond that, the jAlbum core should not be inserting code that a skin then is forced to laboriously try to fix. Please leave styling to the skins - that's what skins do.

I'm also open to allowing skins to control what tags to allow.

This is where we get to the heart of the problem.

Underlining shouldn't be allowed. In HTML, this normally indicates an anchor. It shouldn't be used for anything else, simply because it has a specific, different meaning to a site visitor.

The alignment and indenting tags shouldn't be allowed. These will never work properly in most skins.

The heading tags - <h1-6> - are useless. What do they mean in HTML? They mean, "this is more important than that." How that translates into a display style isn't specified - it's dependent upon the other styling on the page. In fact, Mozilla says, "Avoid using heading tags to resize text." So, you're passing something to the skin that it can't really use, or that's almost certainly going to collide with the skin's own use of those tags. And when it actually does produce size differences, that creates page layout problems.

The ordered and unordered list tags suffer from the same problem as the alignment and indenting - the results will be unpredictable. Try it in Minimal with a few lines of text of varying lengths. Not what the user was expecting, I promise you.

The <blockquote> tag produces almost nothing in HTML. In most browsers, it tries to indent the text, but as we have seen, indenting is a mess.

The anchor tag isn't bad - that may be the only one that is genuinely easier to use than hand-coding. But burying links in titles and comments is not really a wonderful idea. Users like to do it, but I'm not sure their visitors like it. ;)

So what's left? Do we really need a separate editor for italic and bold? If the regular text editing just recognized CTRL-I and CTRL-B, that would be enough.

You have two skin developers who rarely agree about anything both warning their users to stay away from the HTML editor. What does that tell you?

This is one of the not-well-thought-out decisions that we end up struggling with for years. There have been a few of these in the past. Do we really need to go through this again?
davidekholm

Posts: 3,222
Registered: 18-Oct-2002
Re: jAlbum 21 beta for testing
Posted: 17-Jul-2020 14:21   in response to: JeffTucker in response to: JeffTucker
  Click to reply to this thread Reply
Attachment editor.html (10,5 KB)
See if this stripped-down version would be acceptable:
JeffTucker

Posts: 6,883
Registered: 31-Jan-2006
Re: jAlbum 21 beta for testing
Posted: 17-Jul-2020 15:11   in response to: davidekholm in response to: davidekholm
  Click to reply to this thread Reply
Attachment minbullets.png (494,8 KB)
That's certainly better. Now get rid of the ordered and unordered lists. Attached is what happens in Minimal - see the problem?

So what are you left with? Bold, italic, text color, and links. Is that really worth the effort of building it into the app?

And BTW, the bold and italic are no longer showing up, just like what we're seeing on Macs. It's not WYSIWYG. This makes using the editor for even these simple changes almost impossible - you can't tell whether the bold or italic have been applied to the text until you see the result back in the Explore view.
AndreWolff

Posts: 1,766
Registered: 14-Dec-2007
Re: jAlbum 21 beta for testing
Posted: 17-Jul-2020 15:26   in response to: davidekholm in response to: davidekholm
  Click to reply to this thread Reply
davidekholm wrote:
IIf you for instance don't want end users to play with indentation in your skin, just override the indentation style with empty code in your common.css.
So you let a user first make indentations in the html editor, but after a Make he does not see his indentations in the resulting album?
That is very user unfriendly!
AndreWolff

Posts: 1,766
Registered: 14-Dec-2007
Re: jAlbum 21 beta for testing
Posted: 17-Jul-2020 15:41   in response to: JeffTucker in response to: JeffTucker
  Click to reply to this thread Reply
jGromit wrote:
That's certainly better. Now get rid of the ordered and unordered lists. Attached is what happens in Minimal - see the problem?
That is not fair, you should first left align the text and next apply unordered lists,

Unordered lists are very useful, they should stay in the html editor.
However indentations should be removed.
Legend
Forum admins
Helpful Answer
Correct Answer

Point your RSS reader here for a feed of the latest messages in all forums