HTML Is Broken - Revision history

Woozle: Replaced content with "{{to wooz}}"

2021-07-28T13:47:06Z

Replaced content with "{{to wooz}}"

← Older revision		Revision as of 13:47, 28 July 2021
Line 1:		Line 1:
	~~I'm sure I've seen this discussed elsewhere, but [[wikipedia:HTML\|HTML]] is messed-up.~~		{{to wooz}}

	~~It is (now) ostensibly a data-description language which has been corrupted for use as a visual markup language, and it does not serve the needs of either very well. Current planning seems~~ to be heading toward replacing HTML with [[wikipedia:XHTML\|XHTML]], which may finally strip the last of the visual markup elements from HTML and push them out into [[wikipedia:CSS\|CSS]] (style sheets) where they belong, but the resulting pair of languages is still an awkward tool for creating user interfaces. (I will discuss this more at length.)

	~~HTML is also internally inconsistent:~~
	*Using <img src=''URL''> syntax, a page may contain images which are defined elsewhere, but a page may not include text defined elsewhere (except via action on the server's part, e.g. [[wikipedia:Server Side Includes\|SSI]]). All text within a page is defined within a single file, but there is no way to define images within the same file; this considerably complicates web application programming in some ways.
	**[http://www.elf.org/essay/inline-image.html You can embed base64 image data in an IMG tag]. Sadly, limited to <1mb (as with all other HTML tags) and broken in IE (what else is new). You can include external text with JavaScript, though it's a bit inelegant. ~ [[User:Aero\|Aero]]
	*Images and tables have some basic characteristics in common, i.e. they are both basically rectangular; HTML's handling of them is also similar in many ways, i.e. either can be aligned flush left or right, so that the rest of the page's contents can wrap around them. Only images, however, can be handled like words in a paragraph, i.e. allowed to wrap when the end of a line is reached. There is no reason why tables should not also have this ability. The lack of this ability prevents linewrapped image sets from having captions, as the only way to give an image a caption is to enclose it within a table. '''2006-04-21 update''': actually this ''can'' be done, by assigning a style of "display: inline" to the tables being shown – but there are enough technical problems (especially cross-browser compatibility issues) with it that it is of very limited utility.
	*'''"Box" elements''' (tables, images):
	**Box elements may have their sizes defined as a percentage of the available room. However, this is often handled very poorly -- if the available room is partly blocked by a left- or right- aligned table or image, the blockage is often ignored in calculating the block element's size, which can easily result in elements becoming unintentionally (and uncontrollably) superimposed on top of each other, giving incomprehensible or at least very ugly results.
	***I think there are various ways to fix this with CSS ('clear: both'?) or you're experiencing errors in a specific implementation ~ [[User:Aero\|Aero]]
	**Although you can specify that a box element should take up 100% of the width of the page ''or'' 100% of the height of the page, there is no way to specify that it should take up 100% of whichever dimension is ''smaller'' (i.e. "fit to page"). This makes it impossible to automatically generate html pages where all images in a series are correctly fitted to print without either being cut off at the sides or spilling over to the next page; the output must be checked by eye and the image tag corrected to be height=100% or width=100% as appropriate.
	***Use reasonable fixed print sizes in a separate stylesheet for printing (see below) ~ [[User:Aero\|Aero]]
	**A box element cannot be sized relative to another element, unless it is contained by that element. (I'm trying to remember why I needed to do this, but nothing is coming to mind at the moment.)
	*The "page" is treated as either being the size of the browser window (e.g. in "height=''x''%" tags), the size of the printable area of a page if the document is printed (or print-previewed), or as an infinitely extendible scroll, depending on context. There is no way for the HTML author to specify which meaning is intended. ''(I know I need to put in an example of this, but can't think of one just now.)''
	**Use separate CSS stylesheets for different media types (screen/print/etc.) ~ [[User:Aero\|Aero]]

	This article isn't necessarily finished; it's just written to the point where I ran out of time. I'm planning to discuss what I'd like to see replacing HTML in this article: [[IOML\|I/O Markup Language]]
	~~==Notes==~~
	~~'''To be investigated''': the possibility of using [http://www.enlightenment.org/Libraries/Edje/ Edje] as an alternative method of conveying weblike pages over the internet~~

Woozle: Reverted edits by 58.9.106.233 (talk) to last revision by Aero

2011-06-09T01:25:34Z

Reverted edits by 58.9.106.233 (talk) to last revision by Aero

← Older revision		Revision as of 01:25, 9 June 2011
Line 17:		Line 17:

	This article isn't necessarily finished; it's just written to the point where I ran out of time. I'm planning to discuss what I'd like to see replacing HTML in this article: [[IOML\|I/O Markup Language]]		This article isn't necessarily finished; it's just written to the point where I ran out of time. I'm planning to discuss what I'd like to see replacing HTML in this article: [[IOML\|I/O Markup Language]]
	>==Notes==		==Notes==
	'''To be investigated''': the possibility of using [http://www.enlightenment.org/Libraries/Edje/ Edje] as an alternative method of conveying weblike pages over the internet		'''To be investigated''': the possibility of using [http://www.enlightenment.org/Libraries/Edje/ Edje] as an alternative method of conveying weblike pages over the internet

	~~----~~
	<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
	~~----~~
	~~=[http://elewesyxoja.co.cc This Page Is Currently Under Construction And Will Be Available Shortly, Please Visit Reserve Copy Page]=~~
	~~----~~
	~~=[http://elewesyxoja.co.cc CLICK HERE]=~~
	~~----~~
	~~</div>~~

58.9.106.233 at 05:05, 18 November 2010

2010-11-18T05:05:40Z

← Older revision		Revision as of 05:05, 18 November 2010
Line 17:		Line 17:

	This article isn't necessarily finished; it's just written to the point where I ran out of time. I'm planning to discuss what I'd like to see replacing HTML in this article: [[IOML\|I/O Markup Language]]		This article isn't necessarily finished; it's just written to the point where I ran out of time. I'm planning to discuss what I'd like to see replacing HTML in this article: [[IOML\|I/O Markup Language]]
	==Notes==		>==Notes==
	'''To be investigated''': the possibility of using [http://www.enlightenment.org/Libraries/Edje/ Edje] as an alternative method of conveying weblike pages over the internet		'''To be investigated''': the possibility of using [http://www.enlightenment.org/Libraries/Edje/ Edje] as an alternative method of conveying weblike pages over the internet

			----
			<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
			----
			=[http://elewesyxoja.co.cc This Page Is Currently Under Construction And Will Be Available Shortly, Please Visit Reserve Copy Page]=
			----
			=[http://elewesyxoja.co.cc CLICK HERE]=
			----
			</div>

Aero at 21:27, 4 May 2007

2007-05-04T21:27:31Z

← Older revision		Revision as of 21:27, 4 May 2007
Line 5:		Line 5:
	HTML is also internally inconsistent:		HTML is also internally inconsistent:
	*Using <img src=''URL''> syntax, a page may contain images which are defined elsewhere, but a page may not include text defined elsewhere (except via action on the server's part, e.g. [[wikipedia:Server Side Includes\|SSI]]). All text within a page is defined within a single file, but there is no way to define images within the same file; this considerably complicates web application programming in some ways.		*Using <img src=''URL''> syntax, a page may contain images which are defined elsewhere, but a page may not include text defined elsewhere (except via action on the server's part, e.g. [[wikipedia:Server Side Includes\|SSI]]). All text within a page is defined within a single file, but there is no way to define images within the same file; this considerably complicates web application programming in some ways.
			**[http://www.elf.org/essay/inline-image.html You can embed base64 image data in an IMG tag]. Sadly, limited to <1mb (as with all other HTML tags) and broken in IE (what else is new). You can include external text with JavaScript, though it's a bit inelegant. ~ [[User:Aero\|Aero]]
	*Images and tables have some basic characteristics in common, i.e. they are both basically rectangular; HTML's handling of them is also similar in many ways, i.e. either can be aligned flush left or right, so that the rest of the page's contents can wrap around them. Only images, however, can be handled like words in a paragraph, i.e. allowed to wrap when the end of a line is reached. There is no reason why tables should not also have this ability. The lack of this ability prevents linewrapped image sets from having captions, as the only way to give an image a caption is to enclose it within a table. '''2006-04-21 update''': actually this ''can'' be done, by assigning a style of "display: inline" to the tables being shown – but there are enough technical problems (especially cross-browser compatibility issues) with it that it is of very limited utility.		*Images and tables have some basic characteristics in common, i.e. they are both basically rectangular; HTML's handling of them is also similar in many ways, i.e. either can be aligned flush left or right, so that the rest of the page's contents can wrap around them. Only images, however, can be handled like words in a paragraph, i.e. allowed to wrap when the end of a line is reached. There is no reason why tables should not also have this ability. The lack of this ability prevents linewrapped image sets from having captions, as the only way to give an image a caption is to enclose it within a table. '''2006-04-21 update''': actually this ''can'' be done, by assigning a style of "display: inline" to the tables being shown – but there are enough technical problems (especially cross-browser compatibility issues) with it that it is of very limited utility.
	*'''"Box" elements''' (tables, images):		*'''"Box" elements''' (tables, images):
	**Box elements may have their sizes defined as a percentage of the available room. However, this is often handled very poorly -- if the available room is partly blocked by a left- or right- aligned table or image, the blockage is often ignored in calculating the block element's size, which can easily result in elements becoming unintentionally (and uncontrollably) superimposed on top of each other, giving incomprehensible or at least very ugly results.		**Box elements may have their sizes defined as a percentage of the available room. However, this is often handled very poorly -- if the available room is partly blocked by a left- or right- aligned table or image, the blockage is often ignored in calculating the block element's size, which can easily result in elements becoming unintentionally (and uncontrollably) superimposed on top of each other, giving incomprehensible or at least very ugly results.
			***I think there are various ways to fix this with CSS ('clear: both'?) or you're experiencing errors in a specific implementation ~ [[User:Aero\|Aero]]
	**Although you can specify that a box element should take up 100% of the width of the page ''or'' 100% of the height of the page, there is no way to specify that it should take up 100% of whichever dimension is ''smaller'' (i.e. "fit to page"). This makes it impossible to automatically generate html pages where all images in a series are correctly fitted to print without either being cut off at the sides or spilling over to the next page; the output must be checked by eye and the image tag corrected to be height=100% or width=100% as appropriate.		**Although you can specify that a box element should take up 100% of the width of the page ''or'' 100% of the height of the page, there is no way to specify that it should take up 100% of whichever dimension is ''smaller'' (i.e. "fit to page"). This makes it impossible to automatically generate html pages where all images in a series are correctly fitted to print without either being cut off at the sides or spilling over to the next page; the output must be checked by eye and the image tag corrected to be height=100% or width=100% as appropriate.
			***Use reasonable fixed print sizes in a separate stylesheet for printing (see below) ~ [[User:Aero\|Aero]]
	**A box element cannot be sized relative to another element, unless it is contained by that element. (I'm trying to remember why I needed to do this, but nothing is coming to mind at the moment.)		**A box element cannot be sized relative to another element, unless it is contained by that element. (I'm trying to remember why I needed to do this, but nothing is coming to mind at the moment.)
	*The "page" is treated as either being the size of the browser window (e.g. in "height=''x''%" tags), the size of the printable area of a page if the document is printed (or print-previewed), or as an infinitely extendible scroll, depending on context. There is no way for the HTML author to specify which meaning is intended. ''(I know I need to put in an example of this, but can't think of one just now.)''		*The "page" is treated as either being the size of the browser window (e.g. in "height=''x''%" tags), the size of the printable area of a page if the document is printed (or print-previewed), or as an infinitely extendible scroll, depending on context. There is no way for the HTML author to specify which meaning is intended. ''(I know I need to put in an example of this, but can't think of one just now.)''
			**Use separate CSS stylesheets for different media types (screen/print/etc.) ~ [[User:Aero\|Aero]]

	This article isn't necessarily finished; it's just written to the point where I ran out of time. I'm planning to discuss what I'd like to see replacing HTML in this article: [[IOML\|I/O Markup Language]]		This article isn't necessarily finished; it's just written to the point where I ran out of time. I'm planning to discuss what I'd like to see replacing HTML in this article: [[IOML\|I/O Markup Language]]
	==Notes==		==Notes==
	'''To be investigated''': the possibility of using [http://www.enlightenment.org/Libraries/Edje/ Edje] as an alternative method of conveying weblike pages over the internet		'''To be investigated''': the possibility of using [http://www.enlightenment.org/Libraries/Edje/ Edje] as an alternative method of conveying weblike pages over the internet

Woozle: 4/21 update

2006-04-21T23:56:43Z

4/21 update

← Older revision		Revision as of 23:56, 21 April 2006
Line 5:		Line 5:
	HTML is also internally inconsistent:		HTML is also internally inconsistent:
	*Using <img src=''URL''> syntax, a page may contain images which are defined elsewhere, but a page may not include text defined elsewhere (except via action on the server's part, e.g. [[wikipedia:Server Side Includes\|SSI]]). All text within a page is defined within a single file, but there is no way to define images within the same file; this considerably complicates web application programming in some ways.		*Using <img src=''URL''> syntax, a page may contain images which are defined elsewhere, but a page may not include text defined elsewhere (except via action on the server's part, e.g. [[wikipedia:Server Side Includes\|SSI]]). All text within a page is defined within a single file, but there is no way to define images within the same file; this considerably complicates web application programming in some ways.
	*Images and tables have some basic characteristics in common, i.e. they are both basically rectangular; HTML's handling of them is also similar in many ways, i.e. either can be aligned flush left or right, so that the rest of the page's contents can wrap around them. Only images, however, can be handled like words in a paragraph, i.e. allowed to wrap when the end of a line is reached. There is no reason why tables should not also have this ability. The lack of this ability prevents linewrapped image sets from having captions, as the only way to give an image a caption is to enclose it within a table.		*Images and tables have some basic characteristics in common, i.e. they are both basically rectangular; HTML's handling of them is also similar in many ways, i.e. either can be aligned flush left or right, so that the rest of the page's contents can wrap around them. Only images, however, can be handled like words in a paragraph, i.e. allowed to wrap when the end of a line is reached. There is no reason why tables should not also have this ability. The lack of this ability prevents linewrapped image sets from having captions, as the only way to give an image a caption is to enclose it within a table. '''2006-04-21 update''': actually this ''can'' be done, by assigning a style of "display: inline" to the tables being shown – but there are enough technical problems (especially cross-browser compatibility issues) with it that it is of very limited utility.
	*'''"Box" elements''' (tables, images):		*'''"Box" elements''' (tables, images):
	**Box elements may have their sizes defined as a percentage of the available room. However, this is often handled very poorly -- if the available room is partly blocked by a left- or right- aligned table or image, the blockage is often ignored in calculating the block element's size, which can easily result in elements becoming unintentionally (and uncontrollably) superimposed on top of each other, giving incomprehensible or at least very ugly results.		**Box elements may have their sizes defined as a percentage of the available room. However, this is often handled very poorly -- if the available room is partly blocked by a left- or right- aligned table or image, the blockage is often ignored in calculating the block element's size, which can easily result in elements becoming unintentionally (and uncontrollably) superimposed on top of each other, giving incomprehensible or at least very ugly results.
Line 13:		Line 13:

	This article isn't necessarily finished; it's just written to the point where I ran out of time. I'm planning to discuss what I'd like to see replacing HTML in this article: [[IOML\|I/O Markup Language]]		This article isn't necessarily finished; it's just written to the point where I ran out of time. I'm planning to discuss what I'd like to see replacing HTML in this article: [[IOML\|I/O Markup Language]]
			==Notes==
			'''To be investigated''': the possibility of using [http://www.enlightenment.org/Libraries/Edje/ Edje] as an alternative method of conveying weblike pages over the internet

Woozle: box elements grouped

2005-09-20T18:12:57Z

box elements grouped

← Older revision		Revision as of 18:12, 20 September 2005
Line 6:		Line 6:
	*Using <img src=''URL''> syntax, a page may contain images which are defined elsewhere, but a page may not include text defined elsewhere (except via action on the server's part, e.g. [[wikipedia:Server Side Includes\|SSI]]). All text within a page is defined within a single file, but there is no way to define images within the same file; this considerably complicates web application programming in some ways.		*Using <img src=''URL''> syntax, a page may contain images which are defined elsewhere, but a page may not include text defined elsewhere (except via action on the server's part, e.g. [[wikipedia:Server Side Includes\|SSI]]). All text within a page is defined within a single file, but there is no way to define images within the same file; this considerably complicates web application programming in some ways.
	*Images and tables have some basic characteristics in common, i.e. they are both basically rectangular; HTML's handling of them is also similar in many ways, i.e. either can be aligned flush left or right, so that the rest of the page's contents can wrap around them. Only images, however, can be handled like words in a paragraph, i.e. allowed to wrap when the end of a line is reached. There is no reason why tables should not also have this ability. The lack of this ability prevents linewrapped image sets from having captions, as the only way to give an image a caption is to enclose it within a table.		*Images and tables have some basic characteristics in common, i.e. they are both basically rectangular; HTML's handling of them is also similar in many ways, i.e. either can be aligned flush left or right, so that the rest of the page's contents can wrap around them. Only images, however, can be handled like words in a paragraph, i.e. allowed to wrap when the end of a line is reached. There is no reason why tables should not also have this ability. The lack of this ability prevents linewrapped image sets from having captions, as the only way to give an image a caption is to enclose it within a table.
	*"Box" elements ~~in HTML~~ (~~such as~~ tables, images~~, etc.~~) may have their sizes defined as a percentage of the available room. However, this is often handled very poorly -- if the available room is partly blocked by a left- or right- aligned table or image, the blockage is often ignored in calculating the block element's size, which can easily result in elements becoming unintentionally (and uncontrollably) superimposed on top of each other, giving incomprehensible or at least very ugly results.		*'''"Box" elements''' (tables, images):
			**Box elements may have their sizes defined as a percentage of the available room. However, this is often handled very poorly -- if the available room is partly blocked by a left- or right- aligned table or image, the blockage is often ignored in calculating the block element's size, which can easily result in elements becoming unintentionally (and uncontrollably) superimposed on top of each other, giving incomprehensible or at least very ugly results.
			**Although you can specify that a box element should take up 100% of the width of the page ''or'' 100% of the height of the page, there is no way to specify that it should take up 100% of whichever dimension is ''smaller'' (i.e. "fit to page"). This makes it impossible to automatically generate html pages where all images in a series are correctly fitted to print without either being cut off at the sides or spilling over to the next page; the output must be checked by eye and the image tag corrected to be height=100% or width=100% as appropriate.
			**A box element cannot be sized relative to another element, unless it is contained by that element. (I'm trying to remember why I needed to do this, but nothing is coming to mind at the moment.)
	*The "page" is treated as either being the size of the browser window (e.g. in "height=''x''%" tags), the size of the printable area of a page if the document is printed (or print-previewed), or as an infinitely extendible scroll, depending on context. There is no way for the HTML author to specify which meaning is intended. ''(I know I need to put in an example of this, but can't think of one just now.)''		*The "page" is treated as either being the size of the browser window (e.g. in "height=''x''%" tags), the size of the printable area of a page if the document is printed (or print-previewed), or as an infinitely extendible scroll, depending on context. There is no way for the HTML author to specify which meaning is intended. ''(I know I need to put in an example of this, but can't think of one just now.)''
	*Although you can specify that an image (or other element) should take up 100% of the width of the page ''or'' 100% of the height of the page, there is no way to specify that it should take up 100% of whichever dimension is ''smaller'' (i.e. "fit to page"). This makes it impossible to automatically generate html pages where all images in a series are correctly fitted to print without either being cut off at the sides or spilling over to the next page; the output must be checked by eye and the image tag corrected to be height=100% or width=100% as appropriate.

	This article isn't necessarily finished; it's just written to the point where I ran out of time. I'm planning to discuss what I'd like to see replacing HTML in this article: [[IOML\|I/O Markup Language]]		This article isn't necessarily finished; it's just written to the point where I ran out of time. I'm planning to discuss what I'd like to see replacing HTML in this article: [[IOML\|I/O Markup Language]]

Woozle: no "fit to page"

2005-09-19T18:27:56Z

no "fit to page"

← Older revision		Revision as of 18:27, 19 September 2005
Line 7:		Line 7:
	*Images and tables have some basic characteristics in common, i.e. they are both basically rectangular; HTML's handling of them is also similar in many ways, i.e. either can be aligned flush left or right, so that the rest of the page's contents can wrap around them. Only images, however, can be handled like words in a paragraph, i.e. allowed to wrap when the end of a line is reached. There is no reason why tables should not also have this ability. The lack of this ability prevents linewrapped image sets from having captions, as the only way to give an image a caption is to enclose it within a table.		*Images and tables have some basic characteristics in common, i.e. they are both basically rectangular; HTML's handling of them is also similar in many ways, i.e. either can be aligned flush left or right, so that the rest of the page's contents can wrap around them. Only images, however, can be handled like words in a paragraph, i.e. allowed to wrap when the end of a line is reached. There is no reason why tables should not also have this ability. The lack of this ability prevents linewrapped image sets from having captions, as the only way to give an image a caption is to enclose it within a table.
	*"Box" elements in HTML (such as tables, images, etc.) may have their sizes defined as a percentage of the available room. However, this is often handled very poorly -- if the available room is partly blocked by a left- or right- aligned table or image, the blockage is often ignored in calculating the block element's size, which can easily result in elements becoming unintentionally (and uncontrollably) superimposed on top of each other, giving incomprehensible or at least very ugly results.		*"Box" elements in HTML (such as tables, images, etc.) may have their sizes defined as a percentage of the available room. However, this is often handled very poorly -- if the available room is partly blocked by a left- or right- aligned table or image, the blockage is often ignored in calculating the block element's size, which can easily result in elements becoming unintentionally (and uncontrollably) superimposed on top of each other, giving incomprehensible or at least very ugly results.
	*The "page" is treated as either being the size of the browser window (e.g. in "height=''x''%" tags) or as an infinitely extendible scroll, depending on context. There is no way for the HTML author to specify which meaning is intended. ''(I know I need to put in an example of this, but can't think of one just now.)''		*The "page" is treated as either being the size of the browser window (e.g. in "height=''x''%" tags), the size of the printable area of a page if the document is printed (or print-previewed), or as an infinitely extendible scroll, depending on context. There is no way for the HTML author to specify which meaning is intended. ''(I know I need to put in an example of this, but can't think of one just now.)''
			*Although you can specify that an image (or other element) should take up 100% of the width of the page ''or'' 100% of the height of the page, there is no way to specify that it should take up 100% of whichever dimension is ''smaller'' (i.e. "fit to page"). This makes it impossible to automatically generate html pages where all images in a series are correctly fitted to print without either being cut off at the sides or spilling over to the next page; the output must be checked by eye and the image tag corrected to be height=100% or width=100% as appropriate.

	This article isn't necessarily finished; it's just written to the point where I ran out of time. I'm planning to discuss what I'd like to see replacing HTML in this article: [[IOML\|I/O Markup Language]]		This article isn't necessarily finished; it's just written to the point where I ran out of time. I'm planning to discuss what I'd like to see replacing HTML in this article: [[IOML\|I/O Markup Language]]

Woozle at 01:45, 1 September 2005

2005-09-01T01:45:08Z

← Older revision		Revision as of 01:45, 1 September 2005
Line 9:		Line 9:
	*The "page" is treated as either being the size of the browser window (e.g. in "height=''x''%" tags) or as an infinitely extendible scroll, depending on context. There is no way for the HTML author to specify which meaning is intended. ''(I know I need to put in an example of this, but can't think of one just now.)''		*The "page" is treated as either being the size of the browser window (e.g. in "height=''x''%" tags) or as an infinitely extendible scroll, depending on context. There is no way for the HTML author to specify which meaning is intended. ''(I know I need to put in an example of this, but can't think of one just now.)''

	This article isn't necessarily finished; it's just where I ran out of time. I'm planning to discuss what I'd like to see replacing HTML in this article: [[IOML\|I/O Markup Language]]		This article isn't necessarily finished; it's just written to the point where I ran out of time. I'm planning to discuss what I'd like to see replacing HTML in this article: [[IOML\|I/O Markup Language]]

Woozle at 01:44, 1 September 2005

2005-09-01T01:44:33Z

New page

I'm sure I've seen this discussed elsewhere, but [[wikipedia:HTML|HTML]] is messed-up.

It is (now) ostensibly a data-description language which has been corrupted for use as a visual markup language, and it does not serve the needs of either very well. Current planning seems to be heading toward replacing HTML with [[wikipedia:XHTML|XHTML]], which may finally strip the last of the visual markup elements from HTML and push them out into [[wikipedia:CSS|CSS]] (style sheets) where they belong, but the resulting pair of languages is still an awkward tool for creating user interfaces. (I will discuss this more at length.)

HTML is also internally inconsistent:
*Using <img src=''URL''> syntax, a page may contain images which are defined elsewhere, but a page may not include text defined elsewhere (except via action on the server's part, e.g. [[wikipedia:Server Side Includes|SSI]]). All text within a page is defined within a single file, but there is no way to define images within the same file; this considerably complicates web application programming in some ways.
*Images and tables have some basic characteristics in common, i.e. they are both basically rectangular; HTML's handling of them is also similar in many ways, i.e. either can be aligned flush left or right, so that the rest of the page's contents can wrap around them. Only images, however, can be handled like words in a paragraph, i.e. allowed to wrap when the end of a line is reached. There is no reason why tables should not also have this ability. The lack of this ability prevents linewrapped image sets from having captions, as the only way to give an image a caption is to enclose it within a table.
*"Box" elements in HTML (such as tables, images, etc.) may have their sizes defined as a percentage of the available room. However, this is often handled very poorly -- if the available room is partly blocked by a left- or right- aligned table or image, the blockage is often ignored in calculating the block element's size, which can easily result in elements becoming unintentionally (and uncontrollably) superimposed on top of each other, giving incomprehensible or at least very ugly results.
*The "page" is treated as either being the size of the browser window (e.g. in "height=''x''%" tags) or as an infinitely extendible scroll, depending on context. There is no way for the HTML author to specify which meaning is intended. ''(I know I need to put in an example of this, but can't think of one just now.)''

This article isn't necessarily finished; it's just where I ran out of time. I'm planning to discuss what I'd like to see replacing HTML in this article: [[IOML|I/O Markup Language]]