First of all, I want to apologize. I'm quite afraid that the explosion of frustration and disappointment on my last message to this list was one of the triggers (if not the only or main one) igniting the conflict here. I'm really sorry for that: my only intention when joined this list was to contributing into making of HTML5 the best it can be, for web users, content authors, browser and tool implementers, and all other affected parties; and that message didn't help this intention at all.
Before going on, I want to make clear that most of what I express in my mails is an opinion or point of view. I, just like anyone else, may be wrong at any time; and I'm more than willing to accept I am when I'm shown some sustainable evidence or argument proving so. If any of you thinks I'm wrong, on whatever I might say or have said, just let me know, and I'll listen (or read) you. Yet the source of my frustration didn't come from being proven wrong our finding disagreement on some or many suggestions; but on the fact that most of the threads I tried to participate in ended up being ignored or stepping into unrelated side-topics. I'm quite willing to make one more effort to assume good faith, and to take the assumption that my messages went unnoticed, or that I failed to express myself so miserably that nobody was able to get my point, or felt into oblivion for any other unintentional reason; rather than thinking that I'm being deliberatelly ignored. (I might add as well that a cold shower really helps with that :P ). Now, let me add that my opinions are not based on just impulsive thoughts; but on over five years of professional experience as a webmaster, web application developer, and SEO specialist; plus roughly five more as a hobbyist "web tinkerer" (ie: setting up dynamic websites just for the sake of it, with no other purpose than seeing how far could I go before messing things up). I've been also into programming since I was 8; so even if I don't write browsers and authoring tools myself, I normally have a quite approximate idea of how easy/hard something could be to implement. I perfectly know that some people here will have more and deeper experience than me; yet I still think that I have enough background to at least contribute something useful. My first opinion on the current discussion is that there is too much going on. If just an off-topic side comment has been enough to lead some entire discussions astray, I don't think it is possible at all to have a rational and/or useful discussion about so many topics at once. I'd like to (briefly) reply to some of the comments posted on this discussion, and even add a few of my own; but if somebody feels anything of what I say here is worth replying to, then it's probably worth updating the subject to something relevant, splitting this thread into more focused dicussions. To Pentasis's comment "Who ever said that the standards are here for browsers?" and all the replies to it: There are several facts here to keep in mind. First of all, there is a relevant collective among web authors (I can't say how big is it, relative to the entire web authors collective), who simply don't trust browser vendors. And there are quite good reasons for that: Microsoft and Netscape literally *negotiated* HTML3.2, with horrible consequences that we are still suffering over a decade after. Microsoft has single-handedly boicoted the propper adoption of XHTML1 with IE's obnoxious treatment of the "application/xhtml+xml" MIMEtype (and, whether you like it or not, there are some cases where draconian error handling is a feature rather than a drawback, added to the extensibility mechanisms XML offers). There has never been an HTML vs. XHTML debate: IE took the choice away, forcing those who tried to use XHTML to do a lot of extra effort, and it's quite obvious that the affected authors didn't like that too much. Microsoft has also stagnated the evolution of the Web, by deciding to take over a decade before decently implementing CSS2. All those authors who were eager to take the most of the new CSS when it was published are quite pissed off by the fact that a single vendor denied them all these new features, for no other reason than lazyness and the commodity of having the market under a monopoly. These are the most obvious and sound; and I hope people from other sectors can get an idea from here about why there are so many developers that are quite exceptic towards browser vendors choices and claims. Now, we have to add the second fact to the mix: the WHATWG group is mostly made of representatives of browser makers (although Google has recently stepped into the sector with its Chrome browser; I think Ian shouldn't be looked at as another browser maker representative; but still we should keep in mind that it's up to them to replace him with another editor if they feel like it). Top it up with the extra fact that the spec is copyrighted by three of these browser vendors. For those of us who don't trust browser vendors this is, in the best case, scary. Hence, don't expect web authors (at least this subset of them) to blindly trust the vendor-centric WHATWG (by vendor-centric I simply mean that it's composed of browser vendors at its core) from the beginning. By joining this list, providing our feedback, and sharing our opinions and PoV, we are giving the group a chance to earn that trust. How does the group use that chance is up to their members. Of course, we are quite aware that browser vendors have the final say on what do they implement; or at least they think so... But content authors have the final say on what do we use to mark up our documents; and currently we do have a choice: it is possible to perfectly render XHTML2 pages on all currently used browsers (although IE up to 7 can be a bit tricky, due to the lack of CSS2 support). Someone (I won't name that person, because it was a private conversation) told me that if HTML5 didn't meet the requirements of browsers, at the end browsers would implement something else; the same way XHTML2 didn't meet those requirements and browsers aren't going to implement it (actually, by implementing XML, namespaces, and XSLT, they are already implementing enough of XHTML2, but that's a separate point). The same reasoning applies to content authors: if HTML5 doesn't meet authoring requirements, authors will end up authoring with something else. Actually, to put a specific example, there is only one issue that keeps me from using XHTML2 for my current website project (and it's completely unrelated to browsers); and it would currently be the best option: it serves my needs better than XHTML1.x or HTML4.x; and HTML5 isn't mature enough yet to be even taken into consideration for that site. However, the main reason why I joined the lists is that I think HTML5 has the potential to beat (read: become much better) than XHTML2. Enough of that; let's go to the next point: On Wed, Nov 5, 2008 at 10:11 AM, Henri Sivonen <[EMAIL PROTECTED]> wrote: > On Nov 5, 2008, at 10:46, Pentasis wrote: > >> <var> is the best example I think. Why <var> but not <function> <operator> >> <operand> etc. etc. etc.? And if code gets this attention why not language? >> (<verb>, <noun> etc. etc.) If we do it like that it would never work. > > <var>, <cite> and <dfn> (and, one might argue, <em>) are legacy elements > flowing out of a desire to replace <i> with something "semantic". > > Since the elements are part of the HTML legacy, there isn't a great > rationale that would justify their inclusion today if they had never been in > HTML and were proposed as new elements now. This makes me wonder: is the backwards compatibility topic being dealt appropriately? For example, why keep <var> (and others), but drop <big>? Why don't keep <font> as well? It is part of the HTML legacy, after all, and a quite large part if you look at the markup of currently existing documents (I'd bet that it's among the three most used elements in the current web, sharing the podium with <p> and <a>, but can't say for sure). I think following HTML4's and XHTML1's approach and having Transitional and Strict flavors wouldn't be a bad idea (I don't know if the Frameset one would still be needed: <table> + <iframe>; or even <iframe> + CSS's display: table-cell; seems quite cleaner, more flexible, and doesn't require authors to use two separate content models for similar stuff). Browsers wouldn't need to care at all when using their "tag-soup" parsers; and it would be just a matter of feeding one DTD/schema or the other when using an XML parser. It would allow separating "obsolete" stuff that is only kept for backwards compatibility from really structural stuff. The impact of doing this (ordered from the worst to the best side effects): Validator implementers would face quite a deal of extra work, since they'd need to validate for different kinds of document (namely, "Transitional soup", "Strict soup", "Transitional XML", and "Strict XML"). Spec writers will have to properly define the flavours. On this early stage, it could be enough to mark the appropriate stuff in the spec as "transitional"; and then writting the DTD's or similar formalizations once the content model becomes stable enough. Authoring Tool implementers wouldn't face too much issues: if they already make a distinction between HTML4's / XHTML1's flavors, reusing most of the code should be quite doable. For those that don't separate flavours, simply don't expect them to start now :P. Browser implementers would be trivially affected: they'd just need to incorporate both flavors of the DTD/Schema for XML parsing, and at much add a bit of logics to ensure the appropriate one is fed to the parser (but browsers are supposed to already be doing this when they are dealing with XHTML1, so it shouldn't be an issue). Authors who chose Strict doctypes would enjoy a succint, efficient, and non-bloated language allowing them to conciselly and consistently mark up their documents. As soon as different kinds of UAs (including browsers, assistive technologies, and search engines, among others) become aware (read: are updated) of the new markup stuff, users will enjoy a wide variety of benefits. Better bookmarking, smarter hints by assistive technologies, and more representative snippets in SERPs are the first ones that come to my mind. Next point: On Wed, Nov 5, 2008 at 10:22 AM, Markus Ernst <[EMAIL PROTECTED]> wrote: > Pentasis schrieb: >> [...] >> First of all, I want to make it absolutely clear that these ideas are >> strictly dealing with context and semantics. I do not wish to interfere in >> the technical part of the spec. I do understand that sometimes there are >> ideas that may involve technical solutions. My first and foremost concern is >> about having a specification that deals with the naming of elements and >> their usage in such a way that this would give us a standard which will >> enable us to markup content consistantly and flexibally without ambiguity, >> and which is flexible enough to act on-the-fly (so we don't have to wait for >> the next version of the spec if something is missing). [...] > If I understand you correctly, you suggest a very basic set of structural > elements, which are to be flexibally qualified by the authors via the class > attribute. The composition of that set should follow some kind of basic > language logic. > > If I understand HTML correctly, it provides a limited set of pre-qualified > elements, some of them with a more structural emphasis, some of them with a > more semantic (or or even presentational) one. The composition of that set > does not follow a higher logic, but the everyday needs of the common web > author (or what the writers of the spec assume this is). > > (I hope this is understandable; I am not a native English speaker, either.) > > So, supposed I got these both correctly, you do not really talk about HTML, > but about an alternative approach of marking up text documents. I > personnally find thinking about alternative approaches very interesting and > useful for opening up one's mind. Actually, I think that what Pentasis is talking about is nothing else than HTML in its earliest and purest form, untainted by the side effects of the browser wars and the mistakes of the past. Although we can't undo past mistakes, we can learn from them; and put some effort on fixing them. Initially, HTML was entirely structural: no presentation, and no semantics. Just paragraphs, headings, anchors, and few other things. With HTML3.2, there was an atempt to make HTML presentational, and it soundly failed. It was aknowledged as a mistake, and HTML4 (plus CSS) put a good deal of work on fixing it: presentational stuff went out (more preciselly, "deprecated"), and presentation was delegated to a separate language (CSS). HTML only left @class for hooking to external information, and @style for when embedding was more appropriate. Then, to make sure noone was left out, a Strict flavor of the language was published, keeping it "pure", and a Transitional one, keeping all the deprecated stuff on it to ease transition, and to enable document-level backwards compatibility. I hope we all agree this was a good solution and that it worked; but if somebody doesn't, please let me know. (It's true that shortly after came XHTML1, adding quite a bit of confussion to the scene, but that's a separate topic). So, if it worked, why not reuse that approach? Why do we need to go through the same mistakes again? Ok, that's an easy one: we need 'cause we are human :P. Jokes aside; am I really the only one here that sees this as exactly the same thing!? Let me try to make it even clearer: after the 3.2 disaster, it was found that: (1) presentational markup didn't enough to properly control the presentation of webpages; and (2) presentational markup clashed so often with structural markup that markup itself was not reliable anymore to infer the structure of a document: either structure was sacrified in favor of presentation, or presentation was sacrified for structure. Now, Pentasis initial posts were showing up a fact: sematic markup doesn't do enough to properly describe the semantics of webpages. I had already posted some comments and even a few examples showing how semantics and structure can often clash, requiring one to be tweaked to achieve the other. Doesn't sound familiar? Can't we simply apply an equivalent solution to the one we used for an equivalent problem ten years ago? Before going on, here are some of the simplest examples I posted a couple of months ago about this issue: <nav> is the only facility in the spec right now to describe "navigation" semantics; but it also implies a "section" structure: hence there is no means to express "navigation" semantics for something that isn't structurally a "section" (for example, headings of the recent changes to a site in the site's main page, linked to the relevant sections, are quite "navigation" stuff, but they are definitely not sections). Similarly, there is no way to mark something as "tangentially related" without making it a "section" (with the <aside> element). And, for example, what about something that's both "navigation" and "tangentially related" (regardless of wether it is a section or not)? For example, a list of "see also" stuff on a documentation page: you would be forced to markup it as <<a "navigation" section inside an "aside" section>> or as <<an "aside" section inside a "navigation" section>>: none of both reflects the real structure of the page; but they are the only ways to represent both semantics. I know these examples are really simple, and the workarounds wouldn't really hurt that much; but they should be enough to show how we are stepping into the same issues with semantics that we did over a decade ago with presentation. Do we really have to wait to be hurt by the issue before solving it, when we can see it so clearly approaching? I don't know you, but I know I am *not* masochist, so I don't really want to get hurt. Now, to something more specific, we'd need: 1) Some (external to HTML) way to describe semantics. (And no, I don't think RDF, on its current form, is a solution for this; but maybe the solution could be based on or inspired by RDF.) That should be to semantics what CSS is to presentation. And we don't really need to care about browsers quickly implementing it, or about legacy browsers that don't implement it, because currently browsers don't care at all about semantics (at least, not beyond displaying @title values and for default rendering, and rendering can be dealt with through CSS anyway). 2) A way to hook these external semantics to arbitrary elements of a page: we already got @class for this :D 3) A way to add inline semantics when needed. I guess a "semantics" attribute would be the most straight-forward approach. About the format it uses, we should care about it once we have solved 1). If we got that, then we could: 1) Get rid of all the "wannabe semantic" elements that didn't really work well enough, sending them to the deprecated/transitional/supported-for-backwards-compatibility-only limbo. 2) Get rid of all the *new* "wannabe semantic" elements that wouldn't be really serving any purpose (ie: un-bloat the content model) 3) Have the simplest and cleanest markup, the most accurate presentation mechanisms, and the richest semantic descriptions of the last 10 (or even more) years, all in one package. > I agree with you that there are many things in HTML that have a purely > historic legitimation, such as the h1-h6 elements. <h level="n"> would be > much more flexible. I personnally often get mad about the IMO totally > unlogic set of form elements. I would highly appreciate such thigs to be > cleaned up in a new HTML spec. But of course the task ot those who design > HTML5 is not to re-invent the wheel, but to evolve the existing HTML in a > highly backwards-compatible way. I have already mentioned what do I think about the backwards-compatibility requirement, and the way it's being approached. Anyway, I think its also worth pointing out the issue with headings: currently, the spec recommends using <h1> for all levels of headings, but that would mess the hell up on current browsers. Hasn't anybody noticed that? > I made the experience when I suggested a new set of form elements, that I > did not get much response on those contributions. The same might happen to > your suggestions, as they are on a more basic level, than the HTML5 works > act on. I don't think you can blame the people working on HTML5 for this, as > they are quite far in the process, and your suggestions do rather set new > starting points, than contribute to the acutal state of the work. These are quite different cases: the main issue with form elements is that their functionality is normally hardcoded in the browser. Pentasis suggestions (and even my own) would only significantly affect the spec itself and validators; and maybe future "smart browsing" features that aren't yet implemented anyway. Well, that's been a long enough message, and over 3 hours of typing and reviewing stuff are now asking me for a cigarrete, so I'll post again soon with the "additional comments" I was planning to add. I want to remind you all that this message mostly reflects my point of view; and if someone disagrees I'm more than willing to pay attention to your arguments. Also, I think it'd be good to start branching stuff from here rather than keeping the multi-discussion on this thread. Regards, Eduard Pascual
