Share » Forums » Suggestions » Discussion: Encouraging use of HTML...

Discussion: Encouraging use of HTML in text fields

Discussion: Encouraging use of HTML in text fields

Tuesday 31 August 2004 6:31:20 am - 8 replies

Author Message

Ole Morten Halvorsen

Tuesday 31 August 2004 7:35:35 am

Alex,

This is an very interesting topic for discussion Alex! I think it is very important to inform users about the problems they will run into in the long run by mixing content and design. I know I've been sloppy about this. However, if users wants to do something, I personally think you can only inform them about the problems and not force them into anything. Some users are not technical enough to understand the consequence of mixing content and design and will want to mix it despite the long term problems. I agree with you Alex, using the text field is not a good solution and users should indeed be informed about the problems.

Ole M.

Senior Software Engineer - Vision with Technology

http://www.visionwt.com
http://www.omh.cc
http://www.twitter.com/omh

eZ Certified Developer
http://ez.no/certification/verify/358441
http://ez.no/certification/verify/272578

Paul Forsyth

Tuesday 31 August 2004 8:03:20 am

I must admit im a little confused about the benefits an xml text field gives to me as the user and the developer. If im performing system integration then the xml becomes more useful but as a user and developer the xml is firmly locked away. The only part i do see and interact with is within the admin and there i find lots of restrictions.

With the coming relaxation of restrictions in 3.5 plus the new online editor its difficult to speak more about this since those changes may solve most problems. I hope they do.

Separating design from content doesnt require an xml text field in my opinion. If i write:

<div>Hello there</div>

i can write simple css to style this any way i want.

Although you can also use the same css to style output from an xml text field it is more difficult to do so because the class parameter in a xml text field is not the same as the css class. More settings need to be changed to link one 'class' to another 'class'. Arguably more powerful, yes, but it is more complex.

I think this dicussion really centres on import/export and the transformations you can do to the xml. If it isnt in this form then you cant perform these transformations to get the data to/from your other system easily. eZ includes a few tools to help here, such as packaging. Paul Borgermans released an xslt operator a long time ago for this. But to be quite honest there really are not that many tools to make full use of this format.

paul

Alex Jones

Tuesday 31 August 2004 8:47:09 am

<b>Ole:</b> I agree, we cannot, and should not try to force the users into using one specific method if it doesn't fit their need. I'm just concerned that we are sliding into recommending the easy route without showing the downside of it. I am just as guilty as anyone else on this site of doing just that.

<b>Paul:</b> I totally agree with the fact that your example separates content from style. Though, to be honest, I don't think a div tag should be mixed in with your content. If you have something that requires a separate container, then I would go so far as to say that it should be stored separately. This may seem a bit extreme, but it is the only way to truly separate style from content, and ensure long term usability. I hope you don't mind, but I am going to shift to using unordered lists as an example, as I believe they should naturally fit within the content.

From my perspective, the true value of the XML Text field is in allowing us as developers to transform the content down the road. By placing a <i><ul></i> block, or any other (X)HTML specific tag in your code, that tag will have to be defined via XSL, or another transformation language, or removed altogether. Using custom tags, a change can be made in the template files to affect how all instances of that tag are displayed.

Another example that crops up from time to time is the <i><font</i> tag. If someone really needs a font tag, I think they are better off creating a custom tag for their editors that will spit out <i><font ...></i>. In time, when they can finally move away from using the font tag, they may choose to replace it with a span, or eliminate the font tag from the custom tag template altogether. I agree that the use of template classes versus CSS classes does complicate matters far more than it should, and I would like to see it revised.

You are right, this discussion does focus on importing and exporting, though I would also add re-use and redesign as well. In my opinion, content should be stored in a manner that is independent of it's output markup language. Placing HTML within the content breaks that. Actually, it is much the same as using in-line CSS styles everywhere, instead of using classes and IDs. You can go the easy route and apply span tags throughout your templates, but in the long run, you are far better off applying classes and IDs judiciously to elements to allow for full flexibility when changes need to be made.

Using the custom XML tags provides the means to style the content appropriately for a variety of mediums. I haven't used the PDF export system at all, but I am curious as to how it handles having HTML within the content. Is it rendered, or is it output as plain text? What if a user decides they want to use eZ publish as a back-end server for a Flash app?

Sorry if I am rambling on a bit here. This is turning into a great conversation, and I appreciate the differing perspective. :)

Alex
[ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ]

<i>When in doubt, clear the cache.</i>

Paul Forsyth

Tuesday 31 August 2004 9:11:35 am

I think one fact is being mangled here. Alex, when you speak about not using html i gather you are speaking about not using html that does not conform to the latest (or apporved) xhtml spec? At the moment eZ xml tags are transformed to html for presentation. I notice that the present tag templates have a mixture of xhtml and html, though this is constantly evolving from what i can see.

However, the eZ template rendering of their xml spec is only one possible presentation. To go back to my point about the lack of tools to use the xml, maybe what we really need is a better way to integrate xslt. Paul B has started on this but maybe it should go further. Perhaps in parts this could replace templates for rendering of the xml. If we are to decouple the content from presentation we need to do something about the templates the xml relies upon for presentation.

paul

Alex Jones

Tuesday 31 August 2004 9:49:32 am

A good point Paul. Ultimately, I don't think any HTML should be included, whether or not it conforms to standards doesn't really make a difference. There was a time when the <i><font></i> tag was legit, but times change. So, what is compliant now, may not be in the future. Now, that isn't to say that eZ publish couldn't create XML tags that are exactly the same as their XHTML equivalents. Why re-invent the wheel? So, unordered lists in the XML/XSL system may well be made up of <i><ul></i> blocks, but they should be defined as such. Wow, this is going off into a tangent of defining the XML markup which could get complex in its own right. I'll stop now. ;)

I would really like to see the system change into a pure form as well. XML/XSL seems to be the ideal solution. I fully agree, we do need more tools to work with the content in its XML format, which makes it all the more important to ensure that the content is clean going forward. Developers using (X)HTML within their content could be forced to spend a lot of time cleaning up their content, or extending style sheets if eZ publish moves towards XSLT. When I get a chance, I plan to look at Paul's work as it sounds intriguing. :)

While I am enjoying the conversation of the (possible) future direction of eZ publish, and the place of XML/XSL within that, I don't want to get off track. So, to bring this full circle, I think it is important for those of us who are helping others in these forum, to explain the downside of using HTML within their content, even if it turns out to be the ideal/only solution for their current problem.

Alex
[ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ]

<i>When in doubt, clear the cache.</i>

Paul Borgermans

Tuesday 31 August 2004 9:50:31 am

Hi Paul,

I can't follow you on this:

<i>If we are to decouple the content from presentation we need to do something about the templates the xml relies upon for presentation.</i>

For me the separation between content and presentation is perfectly accomplished with the current template system, including the templates for xml tags, isn't it?

From an academic viewpoint, it is right to suppose when you have XML, there should be XSL too. Therefore the xslt template operator was introduced by us (programming credits to Tom Couwberghs, not me, I was only asking for it :-) ).

But there is more than xml content too: quite a few datatypes are not xml at all. To bring them in the realm of xml, these should be transformed to xml first before feeding them to an xsl transformation. And that means another processing layer too.

Also, in my experience, there are only very few developers skilled in XSL writing. The current template syntax is easier imho. And one other thing you will never have with a xsl schema is the access to the features of ezpublish, which makes the current template system far more richer than xsl transforms, even for datatypes!!

About the xml used in the ezxml datatype: well ... it is a bit poor for us. Ideally, I would love to see docbook(lite) support (we need support for mathematical, vector graphics and chemical markup). And then it is useful to do the transforms to whatever with xsl. But I see problems there as well: it is very difficult to incorporate "outside" content. The object tag we have now for example becomes almost impossible without more xsl hooks inside the core of ez publish.

I have voiced xml more in another context however: the way of editing content alla bitflux, xopus, and others that are emerging. This allows a browser to become much more an editing tool than those tiny scroll boxes with the OE. It is OK for small pieces of content, but not beyond say 50 lines of text. In this case it would be mandatory to have the content objects (or part thereof) transformed into pure xml.

Maybe the upcoming OSCOM conference (where the ez crew will participate) may change the evolution of ez publish in this direction I hope.

my 0.02 ยค

-paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Paul Forsyth

Tuesday 31 August 2004 10:14:50 am

Hi Paul,

My last point was fairly generic and idealistic :) The tag templates provide the presentation for the xml, which is fine because even with xml/xsl there has to be a delivery mechanism. I really meant that for the moment this is pretty much the only choice we have. I want more choice. Your point about the non-xml in datatypes is spot on.

Do you know if eZ are rethinking what to do with their xml support?

Better front-end integration with an editing tool would be a great start, whatever it is. Heres hoping for oe2.0...

Alex, this thread is on topic, sort of :) As a developer i like to see what the objectives are for teaching best practise for users. While there is this 'looseness' in what the eZ xml can and cannot do i find it hard to advocate for eZ xml. I want to see

- where it is going
- what it will be used for
- the xml content spec to stabilise and be published
- the datatypes to be included (as Paul spoke about)
- the xml for packages to stabilise, be published and include extensions.
- tools within the admin/front end (enabled by choice of course)

I think that my time is best spent advocating for the proper use of xhtml/css and how to achieve that. For the record i use xml text fields, largely because our clients use the oe and therefore need it to edit content. The other day i mentioned using a text field but to be honest i forgot about the literal tag. For the html editor i used a text field largely to show proof of concept and to highlight how trivial it was to implement such an editor.

Anyway, i would ask for eZ staff to respond to this thread and voice their eZ thoughts.

paul

Alex Jones

Tuesday 31 August 2004 10:42:09 am

Paul F. - Good points, you are right that the thread has been on topic - my apologies for that. I didn't quite see that the topic was larger than I first thought. :) Your points make perfect sense, and as you well know, I am all for advocating the proper use of XHTML/CSS! Ultimately, we all want the content to be as clean as possible without sacrificing end-user functionality and usability, nor future capabilities.

The main reason I brought this up, is the fact that I found myself about to respond to someone, telling them to switch to a text field because it was easier. Once I caught myself, I realized that would be a mistake, and noticed that a couple of other posts were doing the same thing. As I mentioned above, I took your proof of concept and implemented it on a documentation site of my own, quite specifically because it provided me the flexibility I needed. So, instead of spending my time advocating the proper changes, I was trying to side-step the issue.

I too would like to get additional feedback from eZ systems on this topic and the specific points both of you Paul's mentioned.

Alex
[ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ]

<i>When in doubt, clear the cache.</i>

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu