3 ms·

Since HTML will be around for a long time, the author says, we need a mechanism for adding new semantics to the language over time. Well, the W3C already has a

by s_tec 18y ago

Since HTML will be around for a long time, the author says, we need a mechanism for adding new semantics to the language over time. Well, the W3C already has a nice mechanism for doing that called "adding new elements". This system works just fine, and there is no reason to define a monstrosity like <div structure="header"> when defining a new <header> element would accomplish the same goal. The only valid complaint against adding new elements is that IE doesn't apply CSS to elements it doesn't recognize. Fortunately, a simple workaround exists: http://xopus.com/devblog/2008/style-unknown-elements.html http://xopus.com/devblog/2008/style-unknown-elements.html

jerf 18y ago
I think that the situation would end up better in the end if, rather than the W3C trying to define new element after new element after new element, especially if we're going to take the viewpoint that the language will be around after 100 years, we instead simply said: * Use whatever elements you want, subject to some name limitations. * Style those elements using stylesheets however you want. (CSS 3.0 finally, AFAIK, completes the set of CSS elements you need to finish emulating/implementing all HTML elements that exist up to this point, including table.) * Let an entirely separate layer argue about semantics. Use the <link> tag to link in those semantics or something. (The ideal would be XML namespaces but this is HTML, not XHTML.) Define a semantic set that matches today's semantics, let the future define what it needs. Let this be the default if no semantic is chosen. Let a thousand flowers bloom, let the winners win. Ultimately, the whole W3C process is flawed at its very core. It's some small, essentially self-selected group of people/organizatiosn trying to decide how the Web Will Be for the Next Ten Years. That's just stupid, and inimical to the way of the web itself. But this is just too darned simple an idea to get "standardized"... More seriously, one way I know I differ from the HTML and Semantic Web folk is that I fundamentally disagree about the nature of semantics. Semantics are not something a document possesses, it is something that you apply to a document. Marking up text is a way to make it easier to apply semantics, but a sufficiently sophisticated (AI-complete) algorithm could apply semantics to flat text just fine. Indicating what semantics you are using in the document somehow (like an XML namespace) makes it easier for the producer and consumer to agree about their semantics, but the consumer may still ignore it and may still extract or apply their own semantics to the document without contradiction. Think about it this way and my proposal is simply the only natural way to proceed. Believe that "Today is <date>January 20, 2008</date>" is actually any different than "Today is <menu>January 20, 2008</menu>" in some "real" way and this W3C exercise of trying to define THE tag set makes sense. But it's all just tags. Just numbers applied to other numbers. Meaning is brought by the reader in collaboration with the writer, there is no intrinsic meaning.
- russell 18y ago
  I agree. The world of documents is going to evolve and since W3C is a committee type beast, there is a reasonable probability that as the years go by we are going to end up with a horrible number of elements. HTML is going to look like the Java API. Perhaps this proposal could open up "structure" plugins that could be developed independently of the browsers themselves and certainly independent of W3C.
- seldo 18y ago
  A separate layer for semantics is a really excellent idea; something like "cascading semantics sheets"* -- instead of cluttering your markup with tons of extra semantic information, frequently duplicated, just use existing CLASS and ID and attributes, plus CSS selectors, to specify elements and define roles for them within the linked document. Thus if the browser understands this extra semantic information it can use it efficiently, and if it doesn't then you've not made your markup crazily crowded for no reason. * except those would also be CSS, so maybe "cascading semantics documents", or CSD

by s_tec 18y ago

jerf 18y ago

I think that the situation would end up better in the end if, rather than the W3C trying to define new element after new element after new element, especially if we're going to take the viewpoint that the language will be around after 100 years, we instead simply said: * Use whatever elements you want, subject to some name limitations. * Style those elements using stylesheets however you want. (CSS 3.0 finally, AFAIK, completes the set of CSS elements you need to finish emulating/implementing all HTML elements that exist up to this point, including table.) * Let an entirely separate layer argue about semantics. Use the <link> tag to link in those semantics or something. (The ideal would be XML namespaces but this is HTML, not XHTML.) Define a semantic set that matches today's semantics, let the future define what it needs. Let this be the default if no semantic is chosen. Let a thousand flowers bloom, let the winners win. Ultimately, the whole W3C process is flawed at its very core. It's some small, essentially self-selected group of people/organizatiosn trying to decide how the Web Will Be for the Next Ten Years. That's just stupid, and inimical to the way of the web itself. But this is just too darned simple an idea to get "standardized"... More seriously, one way I know I differ from the HTML and Semantic Web folk is that I fundamentally disagree about the nature of semantics. Semantics are not something a document possesses, it is something that you apply to a document. Marking up text is a way to make it easier to apply semantics, but a sufficiently sophisticated (AI-complete) algorithm could apply semantics to flat text just fine. Indicating what semantics you are using in the document somehow (like an XML namespace) makes it easier for the producer and consumer to agree about their semantics, but the consumer may still ignore it and may still extract or apply their own semantics to the document without contradiction. Think about it this way and my proposal is simply the only natural way to proceed. Believe that "Today is <date>January 20, 2008</date>" is actually any different than "Today is <menu>January 20, 2008</menu>" in some "real" way and this W3C exercise of trying to define THE tag set makes sense. But it's all just tags. Just numbers applied to other numbers. Meaning is brought by the reader in collaboration with the writer, there is no intrinsic meaning.

russell 18y ago
I agree. The world of documents is going to evolve and since W3C is a committee type beast, there is a reasonable probability that as the years go by we are going to end up with a horrible number of elements. HTML is going to look like the Java API. Perhaps this proposal could open up "structure" plugins that could be developed independently of the browsers themselves and certainly independent of W3C.
seldo 18y ago
A separate layer for semantics is a really excellent idea; something like "cascading semantics sheets"* -- instead of cluttering your markup with tons of extra semantic information, frequently duplicated, just use existing CLASS and ID and attributes, plus CSS selectors, to specify elements and define roles for them within the linked document. Thus if the browser understands this extra semantic information it can use it efficiently, and if it doesn't then you've not made your markup crazily crowded for no reason. * except those would also be CSS, so maybe "cascading semantics documents", or CSD