Re: [whatwg] Authoring Re: several messages about HTML5
Indeed, and that is why it takes a lot of time, and study of existing tools. With that in mind do you have any suggestions for what tools I should look at? Not overly as it depends on which area of the editor you're currently interested in and various other factors. The biggest thing to check against is Word since it is basically the editor that everyone knows. Word does a lot of stupid things too so you don't want to copy it directly. Experience with users is what you really need and I can't recommend enough finding ways to use the editor in real world situations as much as possible - we use ours as the editor for our wiki so it sees a lot of usage. I agree. Some short cuts are common place, whilst others seem to be very specific to the particular tool. Another challenge for browser based editors is that the browsers define their own short cuts and the editor needs to be a good citizen. The problem is that browsers vary considerably in what short cuts they provide. Opera in particular provides a great deal. This risks interfering with the conventional short cuts for editors, and something I will have to look into very carefully. I feel your pain with having to avoid browser defined shortcuts. The advantage of being a Java applet is that when we have focus our shortcuts override the browsers - except on Mac. We have no end of complaints from Mac users that the keyboard shortcuts use control instead of command, but it's the only way we can realistically avoid the browser's shortcuts and still leverage off of the users existing knowledge of shortcuts. For a JavaScript editor you may need to use this different modifier trick on all platforms. Users definitely love their shortcuts though. Regards, Adrian Sutton.
Re: [whatwg] Authoring Re: several messages about HTML5
At 16:37 -0500 UTC, on 2007-02-25, Adrian Sutton wrote: [...] Dave Ragget wrote: Some short cuts are common place, whilst others seem to be very specific to the particular tool. Another challenge for browser based editors is that the browsers define their own short cuts and the editor needs to be a good citizen. The problem is that browsers vary considerably in what short cuts they provide. Opera in particular provides a great deal. This risks interfering with the conventional short cuts for editors, and something I will have to look into very carefully. I feel your pain with having to avoid browser defined shortcuts. The advantage of being a Java applet is that when we have focus our shortcuts override the browsers - except on Mac. We have no end of complaints from Mac users that the keyboard shortcuts use control instead of command, but it's the only way we can realistically avoid the browser's shortcuts and still leverage off of the users existing knowledge of shortcuts. For a JavaScript editor you may need to use this different modifier trick on all platforms. Users definitely love their shortcuts though. Might this not be solvable by having browsers let users use external editors? (I have this vague notion that OmniWeb offers this, but I may be wrong.) The big 'trick' that would be involved would be to have the editor automatically pipe everything back to the browser. I don't know about Windows, but on a unix system that concept isn't alien. Mac OS X would also have AppleEvents available for this. (I don't know enough about other OSs.) It's a more general problem anyway. Not just for inline editors, but for any text area. The editing possibilities are always much poorer than what dedicated editors offer, and people may be used to. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Authoring Re: several messages about HTML5
| I agree that HTML DOM is not suitable for WYSIWYG editing. | | I beg to differ. It is true that an editing style sheet may be | needed to avoid problems with delivery style sheets that use the | display and visibility properties to hide content, or which use CSS | positioning to layer things in complex ways. But apart from that, | The HTML DOM is just fine as it is. So this means relaxation of requirements - strictly speaking it will not be WYSIWYG anymore. If editing style sheet may be needed then what you will see is not what you will get. There are a couple of problems here. Firstly as far as I know there is not and has never been an editor that does What You See Is *Precisely* What You Get, they all have various ways to help the user understand the structure of the document or visualize physical elements such as page boundaries which don't exist on screen. Furthermore, users don't want to see precisely what they'll get, what they want and what WYSIWYG is really about, is that they can see and work with the document in visual form instead of having to learn a mark-up language and for the rendering to be close enough that they don't need to use preview (or don't have to use it more than as a final check). HTML editors in particular don't provide a precise rendering of the document because no two browsers render a document precisely the same and even the same browser on different machines will render it differently depending on user settings, screen resolution etc. Secondly, HTML DOM is not suitable for WYSIWYG editing because it is an inefficient and difficult representation to use for editing operations. It is perfectly possible to use it to write an editor - it's just not the best representation. For instance, if you have content like: pemThis is strongmy content/strong/em/p If the user then selects is my and applies an inline style (span class='stuff'), with a DOM representation you have a couple of tree operations to perform, plus you probably should do some normalization to ensure that the generated tree structure is consistent regardless of how the content got to this point. However, if you represent the text as an attributed string, you simply add span class='stuff' to the attribute set for is my and it's done. When you serialize the model you have to construct a valid DOM out of it, but it's fairly trivial to make the DOM come out in a consistent form and speed is a lot less of an issue at that point. The attributed string model also has the benefit of better matching the way the user thinks about the document - they rarely think of a tree structure, they think of text with formatting. A good example of the problems caused by the backend model not matching the user's model is http://www.codinghorror.com/blog/archives/000583.html also see my response http://www.symphonious.net/2006/06/12/the-invisible-formatting-tag-probl em/ - there's a whole series of back and forth responses if you have nothing better to do, I seem to write about this far too much. | Manipulating the DOM is a straightforward matter of tree walking | algorithms. The really difficulty is understanding what the users | would like to do. For example, you might type some text and click on | the list bullet button. The enter key then starts a new paragraph | within that list item, whilst enter followed immediately by another | enter starts a new list item. Pressing enter on an empty list item | closes the list. When it comes to the markup produced, you can | conceptualize this in terms of a collection of critics that look for | and fix particular problems, e.g. merging adjacent ul elements, or | for moving leading and trailing whitespace out of inline elements. True, the challenge is always to 1) find out what the user meant and 2) do it. The model you choose can make that task easier or more difficult - in fact it generally does both because no single model is ideal for every editing operation. In our editor, we have a specific list model which is different to both the attributed string model and the DOM model - it simply has a list of LIs that are indented at different levels and have attributes like list type (OL/UL), style attributes etc. There are then a relatively small number of atomic changes users can make to lists (change indent level, change list type or attributes or merge items) and the model knows how to perform them on itself. The model also knows how to serialize itself in terms of a valid HTML document structure. The challenge is then simply mapping user actions to list operations in a way that is intuitive and consistent for users. By picking an appropriate model you can save a lot of effort in terms of keeping the model sane and correct. Lists and tables are excellent examples of where the HTML DOM is not ideal for editing because there are too many extra elements around that the user doesn't want to think about. Reconciling this difference in HTML DOM to user expectations is one of
Re: [whatwg] Authoring Re: several messages about HTML5
Well, not *think* as in make it hard, no :) It needs to be as 'natural' as possible[*]. Still, part of what people consider natural is what they're used to. I don't think we should be too afraid to offer an authoring tool that works a little different from what people are used to (yet no more than necessary). People used to not be used to cars and telephones, but they did get used to them and find them very natural now. Well, you can try and see what users think of it. For better or worse, forcing people to learn is not a popular option for users or integrators of editors. In many cases there isn't a big enough pay off to learn how to use a semantic editor - for cars, driving is so much easier than walking that people are prepared to invest a lot of time into learning, I doubt you can get that big a pay off from a semantic editor. [*] ATAG 1.0 makes some good points about this: don't bother the user unnecessarily. But it doesn't conclude to just let the user mess about. The challenge is to subtly guide the user, without getting in his way. Agreed. If you can introduce a high level of semantics in this style it should work. The challenge is doing it. Again though, don't let me discourage people from trying - I'm always looking for ways to help users drive more value out of their documents including, among other things, leveraging the semantic aspects of HTML better. If you haven't already, you will come to learn that users think visually and they are and probably will always be more interested in their content looking good right there in front of them than on it being all nice and semantic. Depends on the user. The spectrum ranges from those who only care about structure and semantics (perfectly happy with black text on a grey background) to those who only care about looks. The majority is somewhere inbetween. My experience is that the vast majority of users are much closer to only caring about what it looks like than caring about semantics. If you can make it semantic and pretty, you've got a winner. Sander Tekelenburg Regards, Adrian Sutton.
Re: [whatwg] Authoring Re: several messages about HTML5
At 17:33 -0500 UTC, on 2007-02-25, Adrian Sutton wrote: [...] I don't think we should be too afraid to offer an authoring tool that works a little different from what people are used to [...] Well, you can try and see what users think of it. For better or worse, forcing people to learn is not a popular option for users or integrators of editors. Very true. Such a tool should therefore do its magic as much in the background as possible. (And like you I see hurdles that will need to be taken.) Still, reality is that there is more and more legislation around the world that requires at least certain parties to ensure their sites be accesible, and thus does force people to learn to do things more right. So even if a semantic editor would require its users to learn some things, it would still in fact make their life easier than if they need to comply with such legislation using an unfit wannabe-WYSIWYG tool. That group (and a few others) seems a likely potential early adopter. Even if it stays there it would be doing good, but once one or two such groups get used to using such an editor, it will probably 'trickle down' to others. (Btw, I realise there may seem to be some naivity on my part, but that's very much on purpose ;) Cynicism just stops one from even trying.) [...] If you can make it semantic and pretty, you've got a winner. Agreed. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Authoring Re: several messages about HTML5
Still, reality is that there is more and more legislation around the world that requires at least certain parties to ensure their sites be accesible, and thus does force people to learn to do things more right. So even if a semantic editor would require its users to learn some things, it would still in fact make their life easier than if they need to comply with such legislation using an unfit wannabe-WYSIWYG tool. Very true. We've seen a lot of interest in our editor due to the fact that we have an accessibility checker built-in. Sadly there is still a lot of work to be done to help users create accessible pages, but it is a key requirement for a lot of people. Sadly, the other key requirement is that it's very simple and intuitive for users because they don't actually want to spend money on accessibility, they just want to achieve government mandated compliance. Speaking of which, if there was an area that needs significant work to make it more usable for tools. At the moment most of the recommendations are way too vague to be able to check them specifically - often humans would have trouble determining if something was compliant or not, let alone an automated checker. Sander Tekelenburg Regards, Adrian Sutton.
Re: [whatwg] Authoring Re: several messages about HTML5
Speaking of which, if there was an area that needs significant work to make it more usable for tools. At the moment most of the recommendations are way too vague to be able to check them specifically - often humans would have trouble determining if something was compliant or not, let alone an automated checker. Er the end of that first sentence should have mentioned accessibility standards, guidelines and recommendations like WCAG, but I got distracted. Regards, Adrian Sutton.
Re: [whatwg] Authoring Re: several messages about HTML5
- Original Message - From: Adrian Sutton [EMAIL PROTECTED] To: Andrew Fedoniouk [EMAIL PROTECTED]; Dave Raggett [EMAIL PROTECTED] Cc: Karl Dubost [EMAIL PROTECTED]; whatwg@lists.whatwg.org Sent: Sunday, February 25, 2007 2:26 PM Subject: RE: [whatwg] Authoring Re: several messages about HTML5 | I agree that HTML DOM is not suitable for WYSIWYG editing. | | I beg to differ. It is true that an editing style sheet may be | needed to avoid problems with delivery style sheets that use the | display and visibility properties to hide content, or which use CSS | positioning to layer things in complex ways. But apart from that, | The HTML DOM is just fine as it is. So this means relaxation of requirements - strictly speaking it will not be WYSIWYG anymore. If editing style sheet may be needed then what you will see is not what you will get. There are a couple of problems here. Firstly as far as I know there is not and has never been an editor that does What You See Is *Precisely* What You Get, they all have various ways to help the user understand the structure of the document or visualize physical elements such as page boundaries which don't exist on screen. Furthermore, users don't want to see precisely what they'll get, what they want and what WYSIWYG is really about, is that they can see and work with the document in visual form instead of having to learn a mark-up language and for the rendering to be close enough that they don't need to use preview (or don't have to use it more than as a final check). HTML editors in particular don't provide a precise rendering of the document because no two browsers render a document precisely the same and even the same browser on different machines will render it differently depending on user settings, screen resolution etc. Secondly, HTML DOM is not suitable for WYSIWYG editing because it is an inefficient and difficult representation to use for editing operations. It is perfectly possible to use it to write an editor - it's just not the best representation. For instance, if you have content like: pemThis is strongmy content/strong/em/p If the user then selects is my and applies an inline style (span class='stuff'), with a DOM representation you have a couple of tree operations to perform, plus you probably should do some normalization to ensure that the generated tree structure is consistent regardless of how the content got to this point. However, if you represent the text as an attributed string, you simply add span class='stuff' to the attribute set for is my and it's done. When you serialize the model you have to construct a valid DOM out of it, but it's fairly trivial to make the DOM come out in a consistent form and speed is a lot less of an issue at that point. The attributed string model also has the benefit of better matching the way the user thinks about the document - they rarely think of a tree structure, they think of text with formatting. A good example of the problems caused by the backend model not matching the user's model is http://www.codinghorror.com/blog/archives/000583.html also see my response http://www.symphonious.net/2006/06/12/the-invisible-formatting-tag-probl em/ - there's a whole series of back and forth responses if you have nothing better to do, I seem to write about this far too much. | Manipulating the DOM is a straightforward matter of tree walking | algorithms. The really difficulty is understanding what the users | would like to do. For example, you might type some text and click on | the list bullet button. The enter key then starts a new paragraph | within that list item, whilst enter followed immediately by another | enter starts a new list item. Pressing enter on an empty list item | closes the list. When it comes to the markup produced, you can | conceptualize this in terms of a collection of critics that look for | and fix particular problems, e.g. merging adjacent ul elements, or | for moving leading and trailing whitespace out of inline elements. True, the challenge is always to 1) find out what the user meant and 2) do it. The model you choose can make that task easier or more difficult - in fact it generally does both because no single model is ideal for every editing operation. In our editor, we have a specific list model which is different to both the attributed string model and the DOM model - it simply has a list of LIs that are indented at different levels and have attributes like list type (OL/UL), style attributes etc. There are then a relatively small number of atomic changes users can make to lists (change indent level, change list type or attributes or merge items) and the model knows how to perform them on itself. The model also knows how to serialize itself in terms of a valid HTML document structure. The challenge is then simply mapping user actions to list operations in a way that is intuitive and consistent for users. By picking an appropriate model you can save a lot of effort
Re: [whatwg] Authoring Re: several messages about HTML5
My statement HTML DOM model is not suitable for WYSIWYG editing meant not physical limitation but logical one. I agree with you - theoretically it is possible to create some WYSIWYG HTML editor that will be asymptotically close to some ideal. But somewhere on the way to it system will hit a point when it will become a determenistic chaos where each line of code is a perfect finite state automata but the whole system is not manageable. You're right, we agree that HTML DOM is not the right model to use for editing, but I'm not sure that it is impossible to create a maintainable system that uses DOM, it just takes a lot more work. I've also not seen anyone create the perfect editor using any model or any format, plain text editors probably come closest. I suspect that much of the difficult is just the fact that users interact with text in so many different ways and any model is going to hit a point where it is exceptionally difficult to get it to do what the user wants. Yes, practical solution for this is to simplify DOM structure ( you use attributed strings and I am using flat DOM in my http://blocknote.net and couple of other editors) For the record, we're based on the Java Swing Text APIs, so the model architecture we have is similar to that. There isn't a lot of the original Swing classes left in our editor anymore as we've gradually improved various parts by extending or rewriting. I think that HTML WYSIWYG editing solution to be used as htmlarea engine in HTML should not use HTML, at least it should not use HTML DOM as is but something more human visualy comprehensible. I think HTML is far too important a technology to not have WYSIWYG editors for it. For many situations it may be better to use a simpler format and convert to HTML (comments on forums or blog entries for example), but there is a lot of flexibility in just using HTML, not least of all is the fact that the final display format is generally HTML and every time you convert formats it tends to introduce some rendering differences which can frustrate users. For example, a lot of wikis attempt to use a HTML editor to edit their wiki mark-up by converting to and from HTML, but I've never seen anyone do the conversion accurately enough to not annoy users. I normally recommend just using HTML as the storage format in these cases - it's more powerful and thus lets users do more with the wiki, it has existing high-quality editors already available and there's no fidelity lost during conversions. That said, I agree, using the HTML DOM directly for an editor is not something I'd like to seriously try. Andrew Fedoniouk. Regards, Adrian Sutton.
Re: [whatwg] Authoring Re: several messages about HTML5
On Fri, 23 Feb 2007, Andrew Fedoniouk wrote: But there are no consistent WYSIWYG HTML/CSS editor applications in the wild that support in full actor model Writer without knowledge of HTML and CSS. Simply because of the nature of HTML and CSS. I think people need to have some knowledge of the basic kinds of document components available in HTML, e.g. headings, paragraphs, the three kinds of lists, blockquotes, preformatted blocks, various kinds of emphasis and their respective role, hypertext links, images, etc. But, that doesn't mean they need to know the markup, for these components, although that may be helpful. CSS varies from very simple rendering properties to very complex features that require expert knowledge. Providing support for simple features is straightforward. Complex layout features can be hidden as templates that are provided by experts, for example, the palette of slide templates offered to authors by PowerPoint and Impress. CSS experts will also be involved in the preparation of skins or themes that can be applied to the content produced by an editor. | As an example, consider a form field. The user selects the text for | use as a field label and clicks on the field button (part of the | editing toolbar). The editor then inserts the field and sets up the | label. The user then uses the context pane to enter the name of the | field, and to set additional properties. My forms-lite/xforms-tiny | library supports JavaScript expressions for validation constraints, | calculated field values, the context in which the field must be | filled out, and when it is relevant. The user can define these | expressions by filling out the input fields within the context pane | that appear when the field is selected in the wysiwyg pane. | | The context pane isn't a slavish UI for element attributes, but | rather a means to support the tasks that users are expected to do. Here is what I do not understand in your use case: Design of input forms implies design of server side code thus set of programming skills and knowledge of some specific abstractions. Think of the difference between someone able to put together simple spreadsheet applications versus someone with a knowledge of SQL and the theory and practice of relational databases. The spreadsheet developer needs to understand the practical requirements of what they are trying to do, but the server side support is the same for all such spreadsheets and can be provided by someone else. The person with the rich knowledge of SQL etc. could separately include specific spreadsheets as part of a workflow process, but that is an entirely different role from creating the spreadsheets in the first place. The next generation of HTML forms should provide the ease and convenience of spreadsheets for simple applications, without the need for authors to know about scripting and events etc. Dave, I would like to hear your definition of the actor that is supposed to use this. As for me your task really appears a bit out of scope of HTML WYSIWYG editing. Hoping the above helps. p.s. From your website: [BlockNote.Net] allows you to edit your documents exactly as they will appear in all popular browsers. http://blocknote.net/features.shtml I can see why you are focussing on that, but it isn't always appropriate, and it depends on what use cases you are going after. For example, where a website is developed by a team of people with different roles that separate content from page layout. Another example is where content needs to be delivered to a wide range of devices with policies controlling the choice of styling and layout as appropriate to different classes of device. Dave Raggett [EMAIL PROTECTED] http://www.w3.org/People/Raggett
Re: [whatwg] Authoring Re: several messages about HTML5
On Thu, 22 Feb 2007, Andrew Fedoniouk wrote: | On Wed, 21 Feb 2007, Andrew Fedoniouk wrote: | | I agree that HTML DOM is not suitable for WYSIWYG editing. | | I beg to differ. It is true that an editing style sheet may be | needed to avoid problems with delivery style sheets that use the | display and visibility properties to hide content, or which use CSS | positioning to layer things in complex ways. But apart from that, | The HTML DOM is just fine as it is. So this means relaxation of requirements - strictly speaking it will not be WYSIWYG anymore. If editing style sheet may be needed then what you will see is not what you will get. The power of CSS kind of makes this inevitable for the general case as was nicely explained by Daniel Glazman in last year's XTech conference. You can't very well rely on wysiwyg when the style sheet has set display to none and visibility to hidden. When it comes to content management systems and supporting different roles for people in the website team, the use of an editing style sheet is beneficial as it focuses the editing task on the matter in hand -- producing copy -- since the layout job is someone else's responsibility. Special style sheets may also be needed to support certain kinds of templates. These style sheets are provided by the website. This is already commonplace, e.g. for blogging sites. Let's take a look on example you've provided: The enter key then starts a new paragraph within that list item So after enter you will have: Case #1: ul liFirst paragraph. pSecond paragraph./p /li /ul *or* Case #2: ul li pFirst paragraph./p pSecond paragraph./p /li /ul Yes, indeed. Two ways to deal with this are to either configure the stylesheet to make the two cases render identically, or for the editor to include rules that produce the 2nd version. This can be arranged via the notion of markup critics that look for particular patterns and suggest corrections. [Think of a crowd of people hovering over your shoulder as you type] Beside of that , yes, Manipulating the DOM is a straightforward matter of tree walking algorithms.. You're right, I forgot to mention the expert system that directs the tree walking algorithms. Coming from an AI background, I tend to take the heuristic approach for granted. Thanks for the comment on contentEditable. I and doubtful just how useful the attribute would be in practice. I expect that instead most developers will use scripts to determine what can be edited and how. Such scripts will also be able to recognise and support microformats and other templates. Cheers, Dave Raggett [EMAIL PROTECTED] http://www.w3.org/People/Raggett
Re: [whatwg] Authoring Re: several messages about HTML5
On Thu, 22 Feb 2007, Andrew Fedoniouk wrote: In reality WYSIWYG principle has one hidden part: What You See Is What You Will Get and What You Can Change Consistently by Using Solely UI Facilities/Tools. That is real meaning of modern WYSIWYG interpretation. I think I understand what you mean, and that is the wysiwyg approach has to be supplemented by other UI. In my case, this is provided using a context pane that gives users the means to access and manipulate the information that is hidden in the purely presentational wysiwyg pane. The inspiration comes from Visual Basic forms editors where a properties pane is provided for the currently selected object. In my case the context is associated with the position of the editing caret in the wysiwyg pane. Users can widen or narrow the context as needed to look at the properties of ancestor elements. As an example, consider a form field. The user selects the text for use as a field label and clicks on the field button (part of the editing toolbar). The editor then inserts the field and sets up the label. The user then uses the context pane to enter the name of the field, and to set additional properties. My forms-lite/xforms-tiny library supports JavaScript expressions for validation constraints, calculated field values, the context in which the field must be filled out, and when it is relevant. The user can define these expressions by filling out the input fields within the context pane that appear when the field is selected in the wysiwyg pane. The context pane isn't a slavish UI for element attributes, but rather a means to support the tasks that users are expected to do. p.s. with the use of an editing style sheet and the notion of skinning the page as a separate operation, the wysiwyg pane can use CSS to show borders for div elements etc. as appropriate to support the editing task. That is very much application dependent and not a fixed part of the design. Cheers, Dave Raggett [EMAIL PROTECTED] http://www.w3.org/People/Raggett
Re: [whatwg] Authoring Re: several messages about HTML5
- Original Message - From: Dave Raggett [EMAIL PROTECTED] To: Andrew Fedoniouk [EMAIL PROTECTED] Cc: Adrian Sutton [EMAIL PROTECTED]; Karl Dubost [EMAIL PROTECTED]; whatwg@lists.whatwg.org Sent: Friday, February 23, 2007 4:03 AM Subject: Re: [whatwg] Authoring Re: several messages about HTML5 | On Thu, 22 Feb 2007, Andrew Fedoniouk wrote: | | In reality WYSIWYG principle has one hidden part: | What You See Is What You Will Get and What You Can | Change Consistently by Using Solely UI Facilities/Tools. | That is real meaning of modern WYSIWYG interpretation. | | I think I understand what you mean, and that is the wysiwyg approach | has to be supplemented by other UI. In my case, this is provided | using a context pane that gives users the means to access and | manipulate the information that is hidden in the purely | presentational wysiwyg pane. The inspiration comes from Visual Basic | forms editors where a properties pane is provided for the currently | selected object. In my case the context is associated with the | position of the editing caret in the wysiwyg pane. Users can widen | or narrow the context as needed to look at the properties of | ancestor elements. Person that edits VB form and person that wtites blog entry (one of the main sources of web content these days) belong to different groups of actors and these are completely different use cases. There are more or less successfull applications on the market already that support (or assist) WYSIWYG editing for the actor group Web Designer with at least basic knowledge of html and its DOM. This kind of actors are ready to consume concept of properties of ancestor elements. But there are no consistent WYSIWYG HTML/CSS editor applications in the wild that support in full actor model Writer without knowledge of HTML and CSS. Simply because of the nature of HTML and CSS. Think about htmlarea (WYSIWYG editor) or the like element on the blog page. Or htmlarea that allow you to edit richtext e-mail Such widget: 1) shall alow richtext editing without reading HTML specification. 2) shall alow to use of only structural constructs that have strong and clear(consistent) semantic meaning. 3) reaction on all UI actions like pressing Enter key, Ctrl-B, etc. shall be predictable upfront. 4) reaction on all UI actions shall be exactly reproducible - the same set of actions in different instances of the widget shall produce exactly same structure of the content. 5) shall not introduce new entites for the actor that are not related to the main task: creating of the content. 6) shall present (render on the screen) only those markup element/attributes that current actor can change in the current editing context (True WYSIWYG). 7) No hidden information is allowed - author and authenticity principle. etc. | | As an example, consider a form field. The user selects the text for | use as a field label and clicks on the field button (part of the | editing toolbar). The editor then inserts the field and sets up the | label. The user then uses the context pane to enter the name of the | field, and to set additional properties. My forms-lite/xforms-tiny | library supports JavaScript expressions for validation constraints, | calculated field values, the context in which the field must be | filled out, and when it is relevant. The user can define these | expressions by filling out the input fields within the context pane | that appear when the field is selected in the wysiwyg pane. | | The context pane isn't a slavish UI for element attributes, but | rather a means to support the tasks that users are expected to do. Here is what I do not understand in your use case: Design of input forms implies design of server side code thus set of programming skills and knowledge of some specific abstractions. So actor here is a programmer - person who knows about concept of two views: source code and final rendering. For the actor Programmer, why do you think that editing of text : input onvalidate=someformula is harder than sequence of actions: 1) click on the toolbar 2) select 'onvalidate' property in editing property panel and 3) type that formula in the field that appear. ? | | p.s. with the use of an editing style sheet and the notion of | skinning the page as a separate operation, the wysiwyg pane can use | CSS to show borders for div elements etc. as appropriate to support | the editing task. That is very much application dependent and not a | fixed part of the design. Dave, I would like to hear your definition of the actor that is supposed to use this. As for me your task really appears a bit out of scope of HTML WYSIWYG editing. Andrew Fedoniouk. http://terrainformatica.com | | Cheers, | | Dave Raggett [EMAIL PROTECTED] http://www.w3.org/People/Raggett |
Re: [whatwg] Authoring Re: several messages about HTML5
Adrian Sutton wrote: Did you notice in your development of an WYSIWYG HTML editor things from the specification that - were very difficult to implement? - were missing in the HTML language itself to make it easier to control the editing? There are a couple of things to note here. Firstly our editor is written in Java, not JavaScript so the second question doesn't really apply because we're not limited to what can be done in HTML and JavaScript. I think what Karl actually meant was something like: what features are missing in HTML to make it easier to have a correct internal representation of the user's requirements?. But maybe you answered that. Gerv
Re: [whatwg] Authoring Re: several messages about HTML5
On Wed, 21 Feb 2007, Andrew Fedoniouk wrote: I agree that HTML DOM is not suitable for WYSIWYG editing. I beg to differ. It is true that an editing style sheet may be needed to avoid problems with delivery style sheets that use the display and visibility properties to hide content, or which use CSS positioning to layer things in complex ways. But apart from that, The HTML DOM is just fine as it is. Manipulating the DOM is a straightforward matter of tree walking algorithms. The really difficulty is understanding what the users would like to do. For example, you might type some text and click on the list bullet button. The enter key then starts a new paragraph within that list item, whilst enter followed immediately by another enter starts a new list item. Pressing enter on an empty list item closes the list. When it comes to the markup produced, you can conceptualize this in terms of a collection of critics that look for and fix particular problems, e.g. merging adjacent ul elements, or for moving leading and trailing whitespace out of inline elements. p.s. one missing feature in CSS that would really help would be a means to add a forced line break symbol to the rendering of br elements. It is already easy to add a paragraph symbol, but CSS balks at br elements for inappropriate reasons. Dave Raggett [EMAIL PROTECTED] http://www.w3.org/People/Raggett
Re: [whatwg] Authoring Re: several messages about HTML5
At 17:15 -0500 UTC, on 2007-02-21, Adrian Sutton wrote: [...] When people get into writing they want to focus purely on what they are writing and they don't want to have to think for a second about how the authoring tool they are using wants them to work. If you want the tool to succeed you will need to solve the keyboard shortcut problems - they are vital, Agreed. you will also need to make sure that whatever interface you come up with to try and get users to create semantic mark up doesn't require them to think about it. Well, not *think* as in make it hard, no :) It needs to be as 'natural' as possible[*]. Still, part of what people consider natural is what they're used to. I don't think we should be too afraid to offer an authoring tool that works a little different from what people are used to (yet no more than necessary). People used to not be used to cars and telephones, but they did get used to them and find them very natural now. [*] ATAG 1.0 makes some good points about this: don't bother the user unnecessarily. But it doesn't conclude to just let the user mess about. The challenge is to subtly guide the user, without getting in his way. If you haven't already, you will come to learn that users think visually and they are and probably will always be more interested in their content looking good right there in front of them than on it being all nice and semantic. Depends on the user. The spectrum ranges from those who only care about structure and semantics (perfectly happy with black text on a grey background) to those who only care about looks. The majority is somewhere inbetween. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Authoring Re: several messages about HTML5
- Original Message -
From: Dave Raggett [EMAIL PROTECTED]
To: Andrew Fedoniouk [EMAIL PROTECTED]
Cc: Adrian Sutton [EMAIL PROTECTED]; Karl Dubost [EMAIL PROTECTED];
whatwg@lists.whatwg.org
Sent: Thursday, February 22, 2007 3:09 AM
Subject: Re: [whatwg] Authoring Re: several messages about HTML5
| On Wed, 21 Feb 2007, Andrew Fedoniouk wrote:
|
| I agree that HTML DOM is not suitable for WYSIWYG editing.
|
| I beg to differ. It is true that an editing style sheet may be
| needed to avoid problems with delivery style sheets that use the
| display and visibility properties to hide content, or which use CSS
| positioning to layer things in complex ways. But apart from that,
| The HTML DOM is just fine as it is.
So this means relaxation of requirements - strictly speaking
it will not be WYSIWYG anymore. If editing style sheet may be
needed then what you will see is not what you will get.
|
| Manipulating the DOM is a straightforward matter of tree walking
| algorithms. The really difficulty is understanding what the users
| would like to do. For example, you might type some text and click on
| the list bullet button. The enter key then starts a new paragraph
| within that list item, whilst enter followed immediately by another
| enter starts a new list item. Pressing enter on an empty list item
| closes the list. When it comes to the markup produced, you can
| conceptualize this in terms of a collection of critics that look for
| and fix particular problems, e.g. merging adjacent ul elements, or
| for moving leading and trailing whitespace out of inline elements.
In reality WYSIWYG principle has one hidden part:
What You See Is What You Will Get and What You Can
Change Consistently by Using Solely UI Facilities/Tools.
That is real meaning of modern WYSIWYG interpretation.
HTML and its DOM has logical/semantic elements that
have no visual representation at all. Think about DIVs that
are used for wrapping portions of textual data and has no
visual representation. Your style sheet may rely
on some containment in some DIV - so the same
sequence of editing actions made by the user produces
dramatically different (for the user) visual results.
Let's take a look on example you've provided:
The enter key then starts a new paragraph within that list item
So after enter you will have:
Case #1:
ul
liFirst paragraph.
pSecond paragraph./p
/li
/ul
*or* Case #2:
ul
li
pFirst paragraph./p
pSecond paragraph./p
/li
/ul
So even in this simple case you have two options how to make
mapping of action - dom structure.
And now imagine that you will get following markup:
Case #3:
ul
liFirst paragraph./li
pSecond paragraph./p
/ul
Visually and by default this is indistinguishable from the Case #1.
So looking on these two list items user has no clue of
what he/she just did by pressing Enter. Enter press is the most
unpredictable action in all WYSIWYG editors in the wild.
For the simple reason: there is no single unambiguous way
of changing DOM for such an action. Again tree-alike
DOM is simply not suitable for that.
And now try to imagine that all this editing happens
in the presence of CSS, let's say following rule:
li:first-child { border-bottom: 1px solid blue; }
All three cases above will provide different rendering.
And now try to imagine of how you would explain
to the user why that-blue-underline appeared and
why exactly there. And what needs to be done
by the user to change it.
Beside of that , yes, Manipulating the DOM is a
straightforward matter of tree walking algorithms..
Andrew Fedoniouk.
http://terrainformatica.com
| p.s. one missing feature in CSS that would really help would be a
| means to add a forced line break symbol to the rendering of br
| elements. It is already easy to add a paragraph symbol, but CSS
| balks at br elements for inappropriate reasons.
|
| Dave Raggett [EMAIL PROTECTED] http://www.w3.org/People/Raggett
|
|
Re: [whatwg] Authoring Re: several messages about HTML5
Thanks Charles for that really inciteful response. I very much agree with the need to get authoring tool support for semantically richer markup. Microformats are great - but how many people find that they can't be bothered with that level of detail, especially when using a wysiwyg style of editor? Rather than considering this to be somebody else's problem, it seems timely to try and do something about it myself. I am therefore devoting a lot of my time into developing a new kind of authoring environment that combines a semantic view with a wysiwyg view, and which will use dictionaries to generate the markup that few of us can be bothered to write directly. What has this to do with HTML5, I hear you asking? The answer is not about markup per se, but rather about the scripting interfaces that browsers provide, and which make possible writing such authoring tools as cross-browser web applications. It has taken a great deal of effort to coax IE into providing DOM2 ranges, as needed to support detecting the location of mouse clicks and to moving beyond italic and bold as the only kinds of emphasis that IE supports with execCommand and text ranges. Keyboard events are the other major source of pain. The good news is that editing support can be implemented in an interoperably way across all modern web browsers without the need for changes to HTML and without any dependence on designMode or contentEditable. Improvements to keystroke events would be valuable and I look forward to widespread support for DOM3 events. This brings us back to what kind of innovation is needed for the creation of web content. One thought is to respect the separation of roles in teams, for instance, text content, graphics design, user interface design, data modelling and information flows. Authoring tools need to respect this separation of roles and avoid burdening people with tasks that are inappropriate to their roles. If you are a journalist providing copy, then you shouldn't be worried about layout and styling. You would also expect help with finding and linking to appropriate references and photos, although these might be added by someone else. It is quite unlikely that you would be interested in element class attribute values etc. Paper still has lots of advantages for editorial work, and I rather like Malcom Gladwell's The social life of paper http://www.gladwell.com/2002/2002_03_25_a_paper.htm We need to think more about how to enable the kinds of affordances that pen and paper provide for various tasks, and what kinds of web authoring tools this would permit. Dave Raggett [EMAIL PROTECTED] http://www.w3.org/People/Raggett On Wed, 21 Feb 2007, Charles McCathieNevile wrote: On Wed, 21 Feb 2007 03:40:09 +0100, Lachlan Hunt [EMAIL PROTECTED] wrote: Vlad Alexander (xhtml.com) wrote: Thank you Ian. Just one follow-up question. You wrote: ...We could require editors to do this, but since nobody knows how to do it, it would be a stupid requirement. ... Is it due to a flaw in HTML that it is difficult to build authoring tools, such as WYSIWYG editors, that generate markup rich in semantics, embody best-practices and can be easily used by non-technical people? Since much of the content on the Web is created using such authoring tools, can we ever achieve a semantically rich and accessible Web? It's not so much a flaw in HTML's design, as it is the refusal of popular WYSIWYG editor vendors to replace common presentational UIs, such as font styles and colours, with much more useful semantic UIs. I don't believe it's particularly difficult to achieve. It just requires thinking outside the box a little and not simply copying what typical word processing software has done in the past. (Summary: What Hixie said. But I show my reasoning ;) ). Hmmm. It is more complex than that, but not much. It is very easy to use Word to create good clean structured content, which can be straightforwardly transformed to good clean semantic HTML (or PDF for that matter). And likewise, it isn't that hard with other tools. The thinking outside the box a bit has been a solved problem since before Word was a WYSIWYG tool. Deployment, and getting the right features used, is a different story. The trick is in the workflow, or ecosystem, or whatever you call it. People started out in the 80s learning to press the BOLD button, or the larger font button, to make headings. This was easy - it matched what they had done with a typewriter or more commonly with a pen at school, and the set of semantics available matched the small number of possibilities (CAPS, underlining, bold or italic with a fancy golfball typewriter. As people got printers and desktop publishing a few people made the crazy multi-font unreadable pages that were all the rage in the mid-80s (just as multi-coloured headings like the google logo were all the rage in the mid-90s - but seem to have all but vanished now except
Re: [whatwg] Authoring Re: several messages about HTML5
Dave Raggett wrote: I am therefore devoting a lot of my time into developing a new kind of authoring environment that combines a semantic view with a wysiwyg view, and which will use dictionaries to generate the markup that few of us can be bothered to write directly. This project sounds very interesting, although I'm a bit dubious about the benefit of a single WYSIWYG view rather than a series of views presenting how a given document skin would look in different devices (e.g. mobile view, screen reader view, console view, magnifier view, desktop view). This would help with the problem Chaals mentioned of people continuing to view the web as essentially a visual medium. Is this project of yours a public project? Are there more details about what you're trying to do somewhere? Perhaps the best metaphor for the separation of content and styles is skinning or theming, a concept almost as popularly familiar as WYSIWIG itself. Authoring tools need to respect this separation of roles and avoid burdening people with tasks that are inappropriate to their roles. Yes I suspect moving away from single view to workflow models would help here. -- Benjamin Hawkes-Lewis
Re: [whatwg] Authoring Re: several messages about HTML5
On Wed, 21 Feb 2007, Benjamin Hawkes-Lewis wrote: Dave Raggett wrote: I am therefore devoting a lot of my time into developing a new kind of authoring environment that combines a semantic view with a wysiwyg view, and which will use dictionaries to generate the markup that few of us can be bothered to write directly. This project sounds very interesting, although I'm a bit dubious about the benefit of a single WYSIWYG view rather than a series of views presenting how a given document skin would look in different devices (e.g. mobile view, screen reader view, console view, magnifier view, desktop view). This would help with the problem Chaals mentioned of people continuing to view the web as essentially a visual medium. Is this project of yours a public project? Are there more details about what you're trying to do somewhere? The wysiwyg view is for there for the purposes of authoring and different style sheets are likely used for different delivery contexts. I am very much interested in device independent authoring tools as part of larger content management frameworks. The idea of being able to combine content with different skins for different delivery contexts is very appealing. The editor project will be released as an open source project, at least as far as the client side pieces are concerned. It is still at an early stage but a beta release is expected by late Summer. Perhaps the best metaphor for the separation of content and styles is skinning or theming, a concept almost as popularly familiar as WYSIWIG itself. indeed! Daniel Glazman (of nVu fame) pointed out the difficulties of using wysiwyg with the final style sheets in a presentation in XTech 2006. How do you do wysiwyg editing if the style sheet hides the piece you are editing? An authoring environment could provide one style sheet for wysiwyg editing and a range of style sheets for delivery purposes. Authoring tools need to respect this separation of roles and avoid burdening people with tasks that are inappropriate to their roles. Yes I suspect moving away from single view to workflow models would help here. I am organizing a workshop on declarative models of distributed web applications (June 5-6, Dublin, Ireland) with the goal of bringing people together to discuss the modeling, security and usability aspects of future authoring frameworks. Some details can be found here: http://www.w3.org/2006/10/uwa-charter.html#workshops A call for participation will be announced shortly. Getting back to HTML5, I am interested in a clean way to set an editing caret within a document's markup, and independent of the existing designMode/contentEditable/execCommand features. In my work I am using a span element for the caret and manipulating it via the DOM. That works pretty well modulo browser variations for where they break lines. It would be good to have fine control of that too, e.g. to prevent line breaking within words (except after hyphens) and before or after span elements except when adjacent to whitespace. The designMode/execCommand features in IE and copied by other browsers are much to much oriented towards very simple word processing (e.g. wordpad) and a poor match to the needs for editing structured documents. Furthermore the markup generated varies considerably across browsers, though this can be cleaned up to some extent via post processing. HTML5 should include support for editing, but I would strong recomend against standardizing designMode and execCommand in their current form. Dave Raggett [EMAIL PROTECTED] http://www.w3.org/People/Raggett
Re: [whatwg] Authoring Re: several messages about HTML5
On Wed, 21 Feb 2007 10:47:50 +0100, Charles McCathieNevile wrote: As people got printers and desktop publishing a few people made the crazy multi-font unreadable pages that were all the rage in the mid-80s Same goes for the newspaper industry for the first part of the 20th century -- /david_latapie U+0F00 http://blog.empyree.org/en (English) http://blog.empyree.org/fr (Français) http://blog.empyree.org/sl (Slovensko)
Re: [whatwg] Authoring Re: several messages about HTML5
I am therefore devoting a lot of my time into developing a new kind of authoring environment that combines a semantic view with a wysiwyg view, and which will use dictionaries to generate the markup that few of us can be bothered to write directly. As someone who writes a WYSIWYG HTML editor for a living - I wish you the very best of luck, you're going to need it. Writing an editor is one of those problems that seems really easy until you get into it, then it starts looking hard. You get through that and ship it to users and they love it and you pat yourself on the back. After about six months of solid usage users have worked with the editor enough to start getting frustrated about its quirks, limitations and bugs and the complaints start pouring in. Then you *really* understand how big the challenge is. I don't say that to deter you - I'm actually very keen to see what you come up with. The main message to take out of this is that you have to pay attention to and get right the very smallest details because they all make a very big difference to users. When people get into writing they want to focus purely on what they are writing and they don't want to have to think for a second about how the authoring tool they are using wants them to work. If you want the tool to succeed you will need to solve the keyboard shortcut problems - they are vital, you will also need to make sure that whatever interface you come up with to try and get users to create semantic mark up doesn't require them to think about it. If you haven't already, you will come to learn that users think visually and they are and probably will always be more interested in their content looking good right there in front of them than on it being all nice and semantic. To succeed you will need to leverage this by making the content look best right there in front of them when it is semantic. You also need to realize that users are very, very picky. Expect to devote many years reviewing and refining the basic functionality of your editor - stick to the minimum of functionality and get it into the hands of real users doing real work as much as possible. Then use the feedback from them (carefully because they will change their views after using the tool for a period of time) to drive new features and improvements to the way the editor works. Best of luck with it. I'm definitely interested in keeping track of the project. Regards, Adrian Sutton.
Re: [whatwg] Authoring Re: several messages about HTML5
Hi adrian, Le 22 févr. 2007 à 07:15, Adrian Sutton a écrit : As someone who writes a WYSIWYG HTML editor for a living - I wish you the very best of luck, you're going to need it. Writing an editor is one of those problems that seems really easy until you get into it, then it starts looking hard. Did you notice in your development of an WYSIWYG HTML editor things from the specification that - were very difficult to implement? - were missing in the HTML language itself to make it easier to control the editing? Bonus question: Do you think that there are needs outside of HTML itself, but needed for authoring HTML, and would need to be shared among an authoring tools community? -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool ***
Re: [whatwg] Authoring Re: several messages about HTML5
Did you notice in your development of an WYSIWYG HTML editor things from the specification that - were very difficult to implement? - were missing in the HTML language itself to make it easier to control the editing? There are a couple of things to note here. Firstly our editor is written in Java, not JavaScript so the second question doesn't really apply because we're not limited to what can be done in HTML and JavaScript. The only real problem we've seen in terms of HTML limitations for implementing the editor is a lack of granularity in terms of contenteditable. There is some demand to be able to specify an uneditable template to use within the editor and have users fill in and/or edit specific parts of it. Unfortunately there are a number of situations where the editability is ambiguous such as: * when an uneditable element is at the end of the document - is the user allowed to insert another element after it? * when there is an editable paragraph inside an uneditable block, is the user allowed to break the paragraph in two? Can they insert another paragraph after the editable paragraph? In terms of what is difficult to implement - lists and tables, but I'm not sure that's because of the HTML format. Lists and tables are just hard to get right in the first place (even Word's list support is regularly infuriating). In general I don't find that the back-end format matters that much in editing, you just need to parse it into a model that is suitable for an editor. I would hate to have to implement an editor based around a standard DOM model of the HTML document because the user doesn't view the document as a tree - they view it as a string of text. So the model used when editing needs to be more like a string of text than a tree. Bonus question: Do you think that there are needs outside of HTML itself, but needed for authoring HTML, and would need to be shared among an authoring tools community? Nothing that immediately comes to mind, but I'm subscribed here to lurk and provide the perspective of an editor maker where appropriate so as things come up I'll be sure to chime in. Karl Dubost - http://www.w3.org/People/karl/ Regards, Adrian Sutton.
Re: [whatwg] Authoring Re: several messages about HTML5
- Original Message - From: Adrian Sutton [EMAIL PROTECTED] To: Karl Dubost [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org Sent: Wednesday, February 21, 2007 6:45 PM Subject: Re: [whatwg] Authoring Re: several messages about HTML5 Did you notice in your development of an WYSIWYG HTML editor things from the specification that - were very difficult to implement? In terms of what is difficult to implement - lists and tables, but I'm not sure that's because of the HTML format. Lists and tables are just hard to get right in the first place (even Word's list support is regularly infuriating). In general I don't find that the back-end format matters that much in editing, you just need to parse it into a model that is suitable for an editor. I would hate to have to implement an editor based around a standard DOM model of the HTML document because the user doesn't view the document as a tree - they view it as a string of text. So the model used when editing needs to be more like a string of text than a tree. I agree that HTML DOM is not suitable for WYSIWYG editing. Especially in presence of CSS on top of it. HTML/CSS rendering (direct) task is pretty much formalized currently. But WYSIWYG editing is aiming to solve inverse problem - by having image on screen (or intention to have one) it needs to build underlying DOM/CSS. And that task in presence of CSS has no unambiguous solution mathematically speaking - exactly same rendering (image) can be produced by various combinations of HTML/CSS markup/rules. As for illustration to Adrian's comments: This markup: ---start-- ul lione/li litwo/li /ul ---end--- will be rendered as ---start-- * one * two ---end--- There are margins on top and bottom of the list. Problem is that it is *very* hard to visualize what part of what element is participating in formation of the spacing between the lines. For WYSIWYG editing purposes the DOM needs to be flattened to something like this: ---start-- ul-lione/ul-li ul-litwo/ul-li ---end--- Otherwise any WYSIWYG editor shall have 1) sidebar with the text of the 8.3.1 Collapsing margins [1] and around. 2) shall have so called source view. Last version of HTML that allow frustration-less WYSIWYG editing was pure v.3.2 I believe. Practically speaking: richtextarea or something suitable for WYSIWYG on the web shall use some simplified markup (flat DOM). Markup like bbcodes or wikicodes is a good example of such practical formats. Andrew Fedoniouk. http://terrainformatica.com [1] http://www.w3.org/TR/CSS21/box.html#collapsing-margins
