[whatwg] Re: 1 webpage != 1 document
Bronwyn Boltwood wrote: Over on the pmwiki-users mailing list, we're having a discussion about the use of heading tags in the sidebar and document structure. You can read the thread at http://thread.gmane.org/gmane.comp.web.wiki.pmwiki.user/16355. In short, the pmwiki-users list is trying to decide how do we keep headings used in the sidebar from wrecking the outline structure, and from "outvoting" the page's real name in search engine indexes. So far the consensus is to stop using heading in the sidebar, and fake them with some other element. I feel that this is a lesser evil, rather than a semantic improvement. As I see it, the root problem here is that the model of a what webpage is says that it's one document. But when did you last see a well-designed live webpage that contained *just* one document? If the W3C's site was constructed like that, we could only find other W3C pages if they were linked in the body text, because there would be no navigation links. Logically speaking, navigation is never the page content proper unless the page is a sitemap. Best practice in web design demands plenty of site-related content in every page, such as the masthead and navigation bar(s). There may also be document-related secondary content, like a sidebar for a magazine story. Evidently, real webpages contain more than just one document each. Does anyone else agree that the "1 webpage = 1 document" idea is flawed? What if we had a way to mark content separate from the page's primary document, so that user agents can recognize these site-related and document-related chunks, and consider their heading structure separately from that of the primary document? You might want to take a look at what the WHATWG is doing with the Web Apps 1.0 drafts. The sectioning elements and heading structure in particular seem to address this problem. If you have suggestions for improvement, of course you are strongly encouraged to comment on the mailing list. http://www.whatwg.org/specs/web-apps/current-work/#sections http://www.whatwg.org/mailing-list ~fantasai
Re: [whatwg] What exactly is contentEditable for?
Note: I'm changing to because I like Lachlan Hunt's idea of being able to specify multiple content types. Olav Junker Kjær wrote: > I'll describe a use case first, since I think it answers some of your > questions. > > Consider a CMS with a browser-based editing interface. For ease of use, > it is designed so that pages in "edit mode" looks as much like the > public site as possible. Different people are allowed to edit different > parts of the site. E.g. the marketing department are only allowed to > edit the "content area", while the CEO is allowed to edit the header and > footer which is shared on every page, but not allowed to change the > content area. > The CMS toolbar has a lot of custom editing commands like "insert > company logo here", "format text as unreadable legalese" and so on, > which can be used on the editable content. Not seeing the difference between (formerly ) and |contenteditable| so far. > The "killer feature" of contentEditable is that it is orthogonal to > document structure. You can make any element - inline or block, anywhere > in the document - editable, without changing the basic structure of the > document. But if you're going to specify regions that only specific people can access, what's the point of everything being a potent |contenteditable| section? > If an extra element (like ) were required around the > editable content, it would get quite tricky, since this element would > have to be transparent wrt. style and DOM, and it should be able to work > both in block and inline context. It's an editing context. Why would you not want the user to know what region you're editing? Furthermore, it's up to the UA to determine whether a specific element can be styled in a particular way. They could easily just allow you to style as inline for specific |content-type| values (i.e. "text/html"). >> What are you talking about? Why wouldn't a UA use the styling of the >>parent document to style the HTML inside a element? > > They cant, since a textarea contains only character data, not markup. It > would seem a giant hack to me, if browsers would take the plaintext > content of textarea, un-encode it and parse it as HTML, and then render > it and generate a DOM-subtree below the textarea. Well, from an HTML perspective, we can just change to allow unencoded content. It won't validate in a fallback scenario, but they |content-type| won't either, and most browsers support using unencoded content inside anyways, so there's no issue from a practical standpoint. The real problem is XHTML. If you don't encode there, you don't get any content on both Opera and Firefox. So, you have to encode for XHTML. That said, browsers have to decode the contents anyway. How else do they generate the text for the control widget? So the control is already taking text and converting it. The only missing piece is the stage where you parse it into the DOM, and considering that many browsers support things like innerHTML, the code is already there. The real problem isn't the implementation. It's the fact that encoding all those characters is a real pain in the [not neck]. I would have to agree that it's a serious weakness. Of course, if you don't care about fallback, you could just use |data| and put the HTML/XHTML in a separate file... >> Here's how it's conceptually broken: How do you submit the edited >>content without scripting? > > You dont. You use scripting. XMLHTTP requires scripting too, its still a > useful feature. But what you're saying is that they need Javascript AND |contenteditable| support just to edit the content, which is what the page is supposed to allow them to do in the first place. That's really only well supported right now on desktops with Internet Explorer. So, for those who don't have a browser with |contenteditable| support, they can't edit, and for those without Javascript, they can edit but can't submit. With a true form control, you can both edit AND submit on legacy browser that don't enable/support Javascript. Also there's the issue of abuse. Take my suggested element, that allows date information to be displayed in localized form: | 2005-08-16 Since you're editing within a element, and you would normally see the localized date rather than the contained alternative content, the UA editor may just generate the alternative content automatically and just let you edit the date with some sort of date picker. Therefore, the above may act as a date picker on some platforms. But don't worry. We can submit the date using Javascript, right?!? >>How do you edit the content in a legacy >>browser? > > You dont. In a legacy browser, the content is rendered as ordinary > content, but not editable. In most cases this is much better fallback > that showing some incomprehensible code in a textarea. Most people dont > know HTML code. If the people editing the HTML don't know HTML, why the heck are they edi
Re: [whatwg] What exactly is contentEditable for?
Olav Junker Kjær wrote: Lachlan Hunt wrote: How is that any different from a text area form control with a specified accept type of text/html, which would allow a UA to load any external editor (eg. XStandard) or degrade to a regular text area? The point of contentEditable is that some areas of a page can be made editable (and editing toggled on and off), while still maintaining the styling and structure of the document. This is really useful for CMS'es and other kind of editors - template editing and so on. I'm not disputing the fact that there is an unfortunate demand for embedded WYSIWYG editing in web based CMSs, it is the conceputally broken implementation I'm against. contentEditable is quite clean since you just toggle an attribute. No, it's messy because it mixes normal document content with user input in a way that does not, by design, degrade very gracefully at all without scripting. With your proposal, the editable element should toggle between the original content, and a textarea element containing content, Which, from a user's point of view, is how contentEditable is generally implemented by authors within web pages. Take, for example, the example provided on MSDN [1]. That provides both a content editable region and a textarea. Although they are clearly seperated from each other, the concept of switching between the two editing modes is still there. Now, take a look at Cameron Adams' "widgEditor" [2]: an implementation using script to dynamically replacce an ordinary textarea with a content editable region with the ability for the user to switch between the two. now HTML escaped, but still rendered as if it were ordinary content, It had to be escaped because the contains #PCDATA despite the fact that implementations tend to treat it more like CDATA, with the exception that they still process entity and character references. User can edit with plain text editor or UA can load WYSIWYG editor for text/html (or whatever ever MIME type is specified) But this considers the editable content as just an arbitrary content type which should be edited in some external editor. It doesn't necessarily have to be an external editor, that aspect is implementation specific. A UA could quite easily replace the text area with a content editable region, much like the widgEditor script does. Another UA could alternatively load an editor plug-in like XStandard into the page; and another could even, theoretically, launch an application like dreamweaver. The point is that the markup should not be concerned with the actual implementation details, like contentEditable is. The point of contentEditable is that the editable content is HTML The point of the suggested was that the editable content is HTML; what's the semantic difference? and an integrated part of the containing page, which enables much cleaner "in place" editing. Perhaps, cleaner from a user's point of view, but, IMHO, certainly not cleaner from an author's and markup point of view. However, as I've said above, there's nothing stopping a UA implementing the interface for my suggestion like the content editable interface. If you just consider the editable content an arbitrary blob of editable content, you wouldn't e.g. expect styles from the containing document to inherit into the editable HTML, which is a major point of contentEditable. That is conceptually a preview mode and there's nothing stopping the UA providing such a view with either method. In fact, there are several examples of authors providing script based previewing. See Jon Hicks' weblog comment system [3] for one. That particular example uses Textile for editing, rather than HTML, but the concept is still the same and with script enabled, the user should see a preview of the content below, as they type. Also consider that editable areas may contain non-editable islands which aganin may contain editable areas. How would that be expresses using TEXTAREA ? That's a usability nightmare, it wouldn't make much sense for part of the content to be editable and other parts not. If you have seperate sections to edit, provide seperate form fields for each one. I dont see how its "conceptually broken". Well, firstly, because the whole idea of editing a semantic langauge like HTML with a very presentationally oriented WYSIWYG system is broken. That applies to all WYSIWYG HTML editors (not just contentEditable) which are not helped by the presence of presentational toolbar functions (eg. the typical bold, italic, font colour, alignment buttons, etc. found in a typical editor's toolbar). However, even ignoring the problems of WYSIWYG editing for HTML, contentEditable is still conceptually broken. The attribute is behavioural, not semantic, and has no place within a semantic language. Although, there may be some arguments for retaining/standardising the scripting interface for it based on th
