Jump to content

Talk:HTML editor

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

FrontPage's code mangling

[edit]

Reply to David's edit summary comment on the best way to mention FrontPage's code mangling, yes, I think it is better. Pete/Pcb21 (talk) 14:36, 9 Mar 2004 (UTC)

Bias re WYSIWYG

[edit]

The discussion of WYSIWYG in this article is so horribly biased that I don't even know where to start. Can we just rip the whole thing out and start again? Kate | Talk 03:41, 2004 Aug 5 (UTC)

With what, specifically, do you take issue? Andy Mabbett 07:58, 5 Aug 2004 (UTC)
It starts with one neutral sentence describing what a WYSIWYG editor is, then one sentence saying they're easier to use. The entire rest of the article then:
  • Criticises them because they don't produce valid code (without noting that this isn't inherent in the concept of an editor);
  • Refers to "old versions of frontpage" to support this;
  • Criticises them because WYSIWYG "doesn't make sense" for HTML (doesn't it? why not?);
  • Criticises them because the results don't look the same on every browser, without explaining why this should be considered a bad thing;
  • Cites "web specialists" with no references;
  • Makes the dubious claim that "every web browser has bugs";
  • Makes no attempt to then suggest reasons that WYSIWYG editors could be useful.
This whole section could be retitled as "Why you shouldn't use HTML editors" and no-one would notice. Kate | Talk 08:14, 2004 Aug 5 (UTC)
Yes, there's no reason that a WYSIWYDG editor should necessarily produce invalid code. I'm not sure if there happen to be any that do generate valid code. What's DreamWeaver like in this regard, for that matter? As for why WYSIWYG doesn't make sense for HTML, it's simple:
  • Pages can be displayed in many different forms and configurations:
    • different window widths and font scales
    • different browser support and configuration for things like CSS
    • different kinds of presentation (graphical, text, speech, braille....)
  • Even within one mode of presentation, several details are left unspecified by the standard, since HTML is not intended as a graphic design language
DreamWeaver currently produces valid XHTML when. When used by a competent person it has always been possible to configure it to produce code which complied to standards but at the current version it produces pretty clean code by default. I prefer hand-coding and don't use much WYSIWYG, so I was taken aback to learn about this fact from co-workers who only know how to use DreamWeaver.
I suppose the main reason people criticise rendering differences between browsers is that too many web designers come from graphic design backgrounds and are used to having this level of control. If only it could be got into people's heads that the WWW just isn't like that, the world would be a better place.
Maybe I'll think about how I'd refactor the page at some point.... -- Smjg 15:44, 5 Aug 2004 (UTC)
As far as the claim that "every browser has bugs", I agree that it is an unproven assertion (though almost certainly valid). However, I do know at least one source (Elizabeth Castro, Visual Quickstart Guide to HTML, XHTML & CSS) which claims that there are no browsers which fully support the current CSS specifications. Sometimes a browser tries to comply and does so incorrectly (bug), but more often there are tags/attributes which are simply ignored (arguably not so much a bug as a lack of a feature). Maybe that would be a suitable compromise wording?
With regard to your comment about the incumbency on an editor to produce valid HTML, isn't it fair to say that WYSIWYG editors in WYSIWYG mode are in fact not editors but code generators, because in WYSIWYG mode it is not necessary for the human user to interact with the HTML? I agree that it is not inherent that an editor will generate valid code. A C programmer's text editor will not guarantee even compilation, let alone complete ANSI C compliance. However, it is certainly desirable for an automatic code generator to generate syntactically valid code. --Sapphire Wyvern

Attempt at NPOV

[edit]

I have attempted to remove some obvious bias. Some always/all type generalizations removed. "Web specialists" removed. Reworded discussion about WYSIWYG editors, notably HTML is not WYSIWYG. Focused more on difficulties in achieving WYSIWYG when browsers are free to render the structure differently.

WYSIWYG section still needs a reorganization.

WYSIWYM?

[edit]

Dbolton has just added a bit on WYSIWYM editors. But does anybody know of one? As much as there ought to be a few out there, it seems silly to talk about what doesn't exist as if it does.

But I do wonder if the HTML Tags view in Mozilla Composer can sensibly be called WYSIWYM.... -- Smjg 11:50, 24 January 2006 (UTC)[reply]

On second thoughts, I guess it isn't really WYSIWYM insofar as the rendering of CSS positioning can interfere with the ability to see what you mean. But it's not far off. -- Smjg 14:50, 29 March 2006 (UTC)[reply]

"Text" vs "Code" editor?

[edit]

I'd suggest that the term "text editor" for the one class of html editors implies less than what most of them do. Most references I've seen to the discussion between WYSIWYG html editors call the other class "code editors." And users are hand-coders, not hand-texters. HomeSite has certainly always been referred to this way. Just a suggestion. jwilkinson 21:37, 14 April 2006 (UTC)[reply]

Try WebTide from http://webtide.lx.ro. It's a freeware HTML editor with tag completion and CSS comletion

Comparison of HTML editors

[edit]

Shouldn't that section be ripped out of this article? It has its own article already, and since the content isn't somehow linked, it's a purely redundany copy & paste job across two articles. -- Northgrove 22:40, 10 July 2006 (UTC)[reply]

Ugh, sorry, I was confused by the "See also" link pointing to a "comparison", when it was just a redirect to this same article. Removing that link as it should absolutely not be there. -- Northgrove 22:41, 10 July 2006 (UTC)[reply]
The comparison should have its own page, and include more html editors like Adobe GoLive24.225.231.62 16:25, 23 August 2006 (UTC)[reply]
I agree and the new Comparison of HTML editors article should be referenced in the Software comparisons category. --Goa103 09:31, 24 October 2006 (UTC)[reply]
Yes, do separate and create a new article, on Comparison of HTML editors. No, do not put it into a software comparisons category. The public has evolved. It is not too challenging to separate these software articles into different types of software.Dogru144 21:39, 24 December 2006 (UTC)[reply]
Are you aware that this used to be a seperate article, but the consensus was to merge it into here? -Fadookie Talk 11:24, 20 January 2007 (UTC)[reply]
This should be removed as Wikipedia is not a review site, and the list is not full. Where is HTMLPad, heck where is the old Hot Dog Pro? (It is an HTML editor still available). No, kill this portion. Guroadrunner 03:30, 10 April 2007 (UTC)[reply]
There are many comparisons on Wikipedia. Even if sometimes controversial, they are extremely useful, merging several points of view in a synthetic way. Add HTMLPad and Hot Dog Pro if you have info on them.
There is even a category for software comparison, Comparison_of_HTML_editors is juste like the other ones. Plus, there was much redundant material between this page and Comparison_of_WYSIWYG_HTML_editors, looked like a copy-paste of a whole page, which we really don't want (partial information on both sides, one page up to date and the other not, etc.). Merge done. Jrouquie 11:42, 23 October 2007 (UTC)[reply]

issue of memory needed for programs

[edit]

Should not the chart include the amount of memory needed to run and store the program? This can be a large amount and so is not inconsequential.Dogru144 21:41, 24 December 2006 (UTC)[reply]

NVu Spell Check

[edit]

NVu 1.0 (20050620) on Windows has its Edit -> Check Spelling item disabled. The only way I could find to check spelling was by turning on View > Show/Hide > Composition Toolbar and then using the Spell button there. A detailed review is at: http://thephantomwriters.com/free_content/d/h/nvu-software-review.shtml

Confusion re Dynamic Web page

[edit]

Conceptual confusion/mistake on column "Dynamic Web page". It is correlated to "Templates". The "dynamic generation" process "OUT of server" (not a server-side generation). See concept on web template system and dynamic web page. SUGESTION: remove the column. Unsigned October 2006

The software screenshots

[edit]

While it's nice with open source tools, I'm unsure if the focus should be on these three editors. Perhaps Amaya for the W3C curiosity (although I can't say I've heard many actually using it), but otherwise, isn't both Dreamweaver and even FrontPage more used than the others? Quanta Plus has a prominent screenshot but isn't even listed in the comparison! I thought DW was among the most used editors on the web, and any web designer is probably aware of FrontPage + its FrontPage web extensions. -- Northgrove 22:03, 16 December 2006 (UTC)[reply]

[edit]

I'm no moderator but I propose that the links to online editors go either to the List of HTML editors with no bold letters! <-BTW, that ones already there.) or be removed. May I?

Recent re-write

[edit]

I notice that large parts of this article have been rewritten earlier today by Oicumayberight. I'm concerned about the repetition in the paragraph under the heading 'Criticism of WYSIWYG editors'. It seems to say the same thing three times with ever more whacky examples used for emphasis. Is this the three-times repetition trick I heard somewhere that politicians' speech-writers use for rousing an audience, or is there something in there that I'm missing? Nigelj 16:37, 3 January 2007 (UTC)[reply]

That's because in the original article (not titled as "criticism"), there were 3 examples in which unfair criticism of WYSIWYG editors should have been placed elsewhere:
  • Negligence
  • Inexperience
  • Excessiveness
All three of these are examples of bad, web design, not bad software technology. I figure all three needed unique rebutting. The whole section read like "WYSIWYG editing is obsolete, so don't consider using it". Since this is a common practice amongst left-brain types, I decided to make the section about why this common criticism is unfair instead of letting the unfair criticism live un-rebutted. I would be fine with deleting the unfair criticism and moving the whole section to the talk page. Oicumayberight 19:20, 3 January 2007 (UTC)[reply]

I may be out of touch with graphic designers' tools (I spend most of my days writing OO web software these days), but can we have an example of, or an explanation of, what 'Object Editors' are? I've never heard of them as discussed here and can't work it out from what's written. On the same score, what are 'Pallets'? Are these dialog boxes? Maybe another name for panels within some product's main window? Again it's just not a GUI term I'm familiar with, and with no illustration or example of what we're talking about I'm not clear what to visualise. (I have been using, writing and designing GUI user interfaces for some years, so I'm not completely ignorant in this area) Nigelj 16:37, 3 January 2007 (UTC)[reply]

Palette window to be more specific. I linked the confusing terms. Designers use pallet to distinguish from the Dialog boxes that are cumbersome to open and close and specify the type of windows.
Ahh, it's an Apple Mac thing. --Nigelj 20:08, 3 January 2007 (UTC)[reply]
More like a graphic designer thing, regardless of platform. The example showed Adobe systems software, which is Microsoft windows and Unix compatible, often before it's made Mac compatible. Oicumayberight 21:01, 3 January 2007 (UTC)[reply]
HTML Object editor is an emerging term to describe the function rather than format of editing HTML objects. I used it for lack of a better word to describe the state between full text editing and WYSIWYG. I included this because the article's dichotomy of only two modes of HTML editing (text or WYSIWYG) was false. Oicumayberight 19:20, 3 January 2007 (UTC)[reply]
Your link to a blog about storing software objects in a MySql database, and the WP article on software objects don't give me any confidence in all this: neither have anything to do with editing HTML as if it were an object-oriented markup language, which is what I think you have written about. Do you have any examples or references for this? --Nigelj 20:08, 3 January 2007 (UTC)[reply]
The link was just one of many to prove that it's an emerging term. Here's more [1] [2] [3]. You don't need to read through them all to determine that it's an emerging term. However, if you know of a better term to describe HTML objects and the practice of editing them in neither a WYSIWYG or full text mode, feel free to replace the term. Oicumayberight 21:01, 3 January 2007 (UTC)[reply]

Lastly, I'm worried about the bullet points in the 'Criticism of WYSIWYG editors' section now. It seems to read, "Some people say this criticism, but they're wrong, wrong, wrong for all the following reasons..." over and over again. It reads more like a "how to win an argument against people who criticise your editor" guide. If that's a balanced NPOV view, then the subheading is now certainly wrong as there are no criticisms left.

It certainly needs to be made clear again that web pages are used differently by different users, and that that is not just due to some kind of browser-inconsistency bug! Search engines, screen scrapers, portable devices, low-bandwidth clients, small screens, the visually impaired, screen readers etc are all legitimate consumers of our HTML content, and HTML editors have to allow for this.

I was tempted just to revert the whole set of edits, but I'll leave it a while to see what other editors think. --Nigelj 16:37, 3 January 2007 (UTC)[reply]

There are criticisms left, just not left unrebutted. I would be fine with deleting the rebuttals as long as the unfair criticisms are deleted with it. Oicumayberight 19:20, 3 January 2007 (UTC)[reply]
We don't need to get partisan about this! It's not a case of whether a criticism is "fair", but whether it is valid, current and documented elsewhere. Similarly with the established benefits. As an encyclopedia we just try to reflect and report what is known and documented elsewhere. --Nigelj 20:08, 3 January 2007 (UTC)[reply]
I agree. It's shouldn't be a biased article. If I thought the criticism was valid criticism of WYSIWYG technology, I wouldn't have posted the rebuttal. As I said, the criticism is misdirected. A tool shouldn't be criticized for misuse, especially when the misuse was possible without the technology. If you can't blame murder on guns, we shouldn't blame poor web design on web development software technology. Those are valid criticisms of web design practices, just not of WYSIWYG technology. Direct the criticism where it belongs. Oicumayberight 21:01, 3 January 2007 (UTC)[reply]
I don't think it's meant to be this way, but the "WYSIWYG Criticisms" section now comes across as saying that WYSIWYG is the best and anyone who criticizes it is ignorant. The analogies sound like a debate rebuttal rather than an encyclopedia article. I have seen WYSIWYG editors that produce terrible code. It doesn't mean all WYSIWYG is bad, but there is at least some truth to some of the criticisms. There really needs to be more outside evidence to both support and rebut these arguments. 00:05, 16 March 2007 (UTC)
I don't see anything in the article denying that WYSIWYG editors produce less optimal code than some hand code. If there is any bias for WYSIWYG, it's a counter-balance to the bias against. Without the rebuttal, the criticism comes across as saying that the drawbacks of WYSIWYG outweigh the benefits. The only fair criticism is the less than optimal code, which can be fixed in the same WYSIWYG editors in source mode if you know how to hand code. Hand coders just don't like competition from people who don't know how to hand code, but can get by with WYSIWYG code. If WYSIWYG were as bad as hand-coders made it out to be, it would never sell. Oicumayberight 07:30, 7 April 2007 (UTC)[reply]

WebEditor+

[edit]

Took out paragraph referencing WebEditor+ as it was a shameless ad. —The preceding unsigned comment was added by 24.250.216.219 (talkcontribs) 01:40, 2 April 2007 (UTC2)

Criticisms part NPOV

[edit]

I added a NPOV tag for the Criticisms part. The person who wrote it is basically saying "People who critize WYSIWYG programs for bad code are wrong", without giving any evidence to prove it. 74.120.133.109 23:56, 6 April 2007 (UTC)[reply]

You appear to be reading into the rebuttal. Please be specific about which statements you feel are inaccurate or biased. Please provide evidence to the contrary of those statements. Oicumayberight 07:36, 7 April 2007 (UTC)[reply]
But the entire section reads like a rebuttal. Under the criticisms section, the first bullet is pretty much correct. I disagree with the next several bullets, though. You are misrepresenting the criticisms.
The problem is that HTML is not a visual language. You specify what something is (header, citation, paragraph) and the users software will render the HTML how the software sees fit. WYSIWYG editors give the web page designer the impression that their HTML document is going to be displayed that way on all browsers.Altarbo 04:30, 30 April 2007 (UTC)[reply]
I requested evidence to the contrary of any of the statements. "I disagree" is not evidence to the contrary.
As for your point about HTML not being a visual language, it may not have been designed for sophisticated visual display, but that's the way it's commonly used. The web browser is a visual medium. The language of the browser is HTML. Sure, there are other languages used in web browsers, but they are not perfect either. The real problem is inconsistency between browsers in how they interpret and display the languages. It has little to do with the tools used to code the languages.
I'm sure most people who use WYSIWYG editors know that they are not perfect. And those who get the wrong impression, learn about the browser inconsistencies pretty quickly. That's no reason to reject the technology altogether. Computing for any purpose in general is full of bugs and instabilities. Are you going to stop using computers because of it?
Those who come from design for print have dealt with a similar problem with inconsistencies between desktop publishing software and imagesetters interpreting PostScript language. The solution was not to hand code all PostScript. It took years before DTP software became fully compatible with imagesetters. Desktop publishers learned to live with PostScript problems just as they are learning to live with inconsistent display between browsers. The inefficient code generated from WYSIWYG editors is improving just as quickly as consistent display between browsers is improving. Oicumayberight 08:58, 30 April 2007 (UTC)[reply]
I've attempted to cite some specific passages Here.
I think specific passages are not the problem though. The entire premise is flawed. HTML is displayed on computers. PostScript is designed for print materials. WYSIWYG is not possible on HTML. Rather than throw blame around, the article should adress why.Altarbo 21:53, 4 May 2007 (UTC)[reply]

May 15 Edits

[edit]

I don't edit Wikipedia that much, so if this is just wasting space, I apologize. It seemed like there was conflict over what should be in this article though, so I thought I should explain my edits. Feel free to disagree or question.

  • I removed "So called". There wasn't a need for it, and it was derisive.
  • I removed two of the images for WYSIWYG. It seemed cluttered to have a ton of images making the same point. I also added the Macromedia Homesite screenshot on Wikipedia. However, the screen is low quality. There should be better screenshot of a text editor and a screenshot of an "object editor". The article mentions some Adobe software, but the only screens already on Wikipedia were not of an object editing mode.
  • I removed actually. Wasn't needed and seemed unproffesional.
  • I replaced the criticisms section with a paragraph explaining the problems of WYSIWYG editing. The criticisms section before made it sound like there was some great divide between text and WYSIWYG editing. This does not reflect reality. Many people use both, and many editors have both modes available. I also felt that the "Problems achieving . . . " section addressed most of the criticisms very well.
  • I added three sources. This is probably more than necessary. The first source deals with CSS support. The second source deals with different displays. It talks about how web designers should be careful with WYSIWYG and test for many platforms. The third source backs up proffesional use of text editors.Altarbo 08:50, 15 May 2007 (UTC)[reply]

What does operating system support mean?

[edit]

The meaning of this table is unclear. Does operating system support mean that the software is compatible, or that tech support is still provided. If it means that the software is (or isn't) compatible, are we only concerned with the latest version? What exactly does "dropped" mean? Perhaps a legend would clear things up. Oicumayberight 16:42, 26 September 2007 (UTC)[reply]

Stream editing of HTML?

[edit]

I visited this wikipedia topic in the hope of finding a pointer to some tools for stream editing of HTML, just as sed can be used as a stream editor for plain text, or xml-sed can be used to stream edit valid XML. Since HTML often isn't valid XML, the xml-coreutils can't be used, and I was hoping to find mention of something similar for HTML. Lukekendall (talk) 13:21, 7 October 2019 (UTC)[reply]

History

[edit]

It is absent. What was the first real HTML editor? CoffeeCup Software says they made the first one.. --85.102.127.183 (talk) 11:22, 3 February 2009 (UTC)[reply]

The first HTML editor was also the first web browser and web server: WorldWideWeb, an application running on Tim Berners-Lee's NeXT desktop.—Chowbok 20:55, 26 July 2011 (UTC)[reply]
[edit]

The image File:Macromedia HomeSite.png is used in this article under a claim of fair use, but it does not have an adequate explanation for why it meets the requirements for such images when used here. In particular, for each page the image is used on, it must have an explanation linking to that page which explains why it needs to be used on that page. Please check

  • That there is a non-free use rationale on the image's description page for the use in this article.
  • That this article is linked to from the image description page.

This is an automated notice by FairuseBot. For assistance on the image use policy, see Wikipedia:Media copyright questions. --22:59, 8 February 2009 (UTC)[reply]

Online editors

[edit]

The section Online editors starts by saying "There are many online WYSIWYG HTML editors; some of them are listed here:". There are then 7 wikilinks to articles on editors. I saw that after that there were then 4 external links to webpages on other editors, including one recently added by an IP editor. I removed those 5, with the edit summary: "Remove those not sufficiently notable to have had Wikipedia articles written about them". The IP has now added them back. Does the community feel that such a list should include products which do not have Wikipedia articles? If they should be included then of course WP:EL would say that there shouldn't be external links within the article body text, so they ought to be plain text entries with references to the external websites. --David Biddulph (talk) 17:27, 11 February 2015 (UTC)[reply]

Assessment comment

[edit]

The comment(s) below were originally left at Talk:HTML editor/Comments, and are posted here for posterity. Following several discussions in past years, these subpages are now deprecated. The comments may be irrelevant or outdated; if so, please feel free to remove this section.

Comment(s)Press [show] to view →
This page contains my comments on the Criticism section of the HTML editor article and the original article with hyperlinks to my comments in bracketed superscript.Altarbo 21:53, 4 May 2007 (UTC)[reply]

==Criticisms of WYSIWYG editors== WYSIWYG editors facilitate the generation of web pages by people with little experience or knowledge of HTML. Experienced hand coders are prone to criticize the editing technology for the neglectful editing habits of the person editing, analogous to faulting automobile technology for reckless driving.[ NPOV ] Because WYSIWYG editors make it easy to build web pages, the editing technology is often faulted for the inexperience of the person editing, analogous to faulting digital cameras for amateur photography.[ NPOV ] Because WYSIWYG editors make complex visual layouts easier to create, the editing technology is often faulted for problems due to complexity of the layout. [ NPOV ]

WYSIWYG editors are sometimes criticized for the following reasons:

  • Depending on the version, WYSIWYG may not automatically generate the most efficient HTML and CSS code. However the code can be edited or generated by hand in WYSIWYG editors. Although third-party optimizers offer solutions to problems from automatically generated code, many of them simply remove extra spaces, rather than looking into the code to remove unneeded structures like compilers do. Unless the optimizer operates as a plug-in for the editor, it cannot take the web author's optimal preferences into account when content is created, resulting in mis-optimized code.[ This section is fine. ]
  • WYSIWYG editors make it easier to create layouts with HTML tables as an alternative to or combined with CSS.[ misrepresentation ] This is not a criticism of WYSIWYG editors as much as it is a criticism of HTML tables. Table based layouts are considered less efficient to download than CSS. Tables add complexity and obfuscates the documents' structures, resulting in code that is more difficult to maintain in text editing modes than CSS. WYSIWYG editors allow for table-free layouts and CSS as well as text editors allow for HTML tables. [ Bullet three ]
  • Users may be disappointed that the same page is rendered differently in different browsers, on various screen sizes, and on varying monitor settings. This criticism is also misplaced. With the exception of Microsoft FrontPage, WYSIWYG editors mainly use W3C standard code.[ irrelevant ] There are many factors outside of the page designer's control that can affect this—the CSS specification and modern browsers even allow users to override a page author's settings. The inconsistent browser display problem is due to inconsistent web browser technology, not WYSIWYG editing technology. [ misleading ]see Difficulties in achieving WYSIWYG below.
  • Documents edited visually without regard to semantic structure can be incomprehensible to search engines, audio and text-only browsers. This is also a criticism of editing habits, not WYSIWYG editing technology. Search engines and browser technology may adapt to the habits of people as well as people will adapt to machines. Artificial intelligence may eventually enable machines to recognize and correct even the rarest problems in both editing and browsing.[ OR ] [ Bullet Three ] =HTML_editor&oldid=127374991#Criticisms_of_WYSIWYG_editors

==Notes== ===NPOV=== These analogies are very NPOV.

WYSIWYG:Text::Car:Horse?

WYSIWYG:Text::Digital Camera:Flash Photography?

These metaphors either ignore the existance of Text Editors or casually deride them. Digital photography and automobiles offer significant advantages over previous technologies. A WYSIWYG editor offers almost no advantage to a user capable of writing their own HTML. It also comes with tons of disadvantages.Altarbo 21:54, 4 May 2007 (UTC)[reply]

===
Misrepresentation
===

WYSIWYG editors give the user the impression that what they see is what their visitors will get. This is especially untrue with tables and gives users the impression that they can use tables for visual/layout purposes, when in reality, tables are displayed differently across browsers and relying on tables (instead of CSS) will create a document that looks radically different to different visitors.Altarbo 21:54, 4 May 2007 (UTC)[reply]

===Bullet three=== The problems in the fourth and second bullet are simply facets of the problem from the third.Altarbo 21:54, 4 May 2007 (UTC)[reply]

===
Irrelevant
===

The web was designed to be viewable on many different devices. The minimum requirments that Tim Berners Lee included with his original paper on the World Wide Web included a 30x80 pixel black and white display. W3C standards have nothing to do with a page displaying a static constant image. They involve the opposite.Altarbo 21:54, 4 May 2007 (UTC)[reply]

Edit: It was 24x80.[1]Altarbo 23:49, 4 May 2007 (UTC)[reply]

===Misleading=== This is a misleading statement. Consistent web browser technology is not going to happen any time soon. A black and white PDA, a cell phone, a standard desktop computer, and a laptop are very different platforms. Cell phones have a portrait oriented small screen, a PDA can have a black and white screen , no audio, and a landscape oriented screen; and a desktop computer can output pure audio.Altarbo 21:54, 4 May 2007 (UTC)[reply]

===OR===

This goes beyond OR. This is not cited and it is unfounded speculation.Altarbo 21:54, 4 May 2007 (UTC)[reply]

Last edited at 13:15, 13 May 2007 (UTC). Substituted at 19:59, 1 May 2016 (UTC)

References

  1. ^ Tim Berners-Lee (March 1989, May 1990). "Information Management Proposal". {{cite journal}}: Check date values in: |date= (help); Cite journal requires |journal= (help)