Re: [whatwg] SPOOFED: Re: SPOOFED: Re: ---
On Mon, Nov 10, 2008 at 2:57 PM, Pentasis <[EMAIL PROTECTED]> wrote: > Hi, > > I seem to have a few problems here, but nothing I cannot handle. For some > reason I get my e-mails later than I should and they are working on the > electricity grid here, so I have no power during the day (only at night). > On the other hand that gave me some time today to think about ti and I > already wrote some stuff down on paper. I will type it tonight. What > file-type do you prefer, is word 95 ok? I'd rather suggest plain text or, if you really need some formatting, html. After all, it would be a quite reasonable assumption that most people in the list can view HTML documents, but it wouldn't be too safe to asume they can view word proprietary format; and even if they can, it can sometimes take some extra work to do so (for example, loading it into Google Docs or the like), and the final document would be significantly bigger in .doc than in .html. Just my opinion.
Re: [whatwg] SPOOFED: Re: SPOOFED: Re: ---
On Sun, Nov 9, 2008 at 4:13 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Sat, 8 Nov 2008, Eduard Pascual wrote: >> >> Can somebody put forward any technical argument against this idea? > > For my benefit, could you succintly summarise the changes that this would > involve to the spec? I'm not sure I really understand the proposal at the > concrete level. Sure! I'd like to speak with Pentasis first (it was him who started this thread with this suggestion), to make sure we have the similar idea in mind (or to cover both viewpoints if needed), before putting something more concrete together, so just give us a couple of days or so to discuss these details; and we'll make our best to word it in a succint and concrete way. > Also, it would be helpful to have a clear summary of the use cases. Definitely, it would. I'll try to put together the cases Pentasis and I have in mind, and also do some research through the web to try find out those cases that might have gone unnoticed. So, expect a more formal (and concrete) reply within a few days.
Re: [whatwg] SPOOFED: Re: SPOOFED: Re: ---
On Sat, 8 Nov 2008, Eduard Pascual wrote: > > Can somebody put forward any technical argument against this idea? For my benefit, could you succintly summarise the changes that this would involve to the spec? (Not the exact wording, but a basic overview of what you see being added or changed.) I'm not sure I really understand the proposal at the concrete level. Also, it would be helpful to have a clear summary of the use cases. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SPOOFED: Re: SPOOFED: Re: ---
On Wed, Nov 5, 2008 at 8:47 PM, Philipp Serafin <[EMAIL PROTECTED]> wrote: > On Wed, Nov 5, 2008 at 4:00 PM, Leons Petrazickis > <[EMAIL PROTECTED]> wrote: >> It matters in the sense that web browsers would have to implement both >> approaches for backwards compatibility. >> > > This depends what you mean when talking about "implementing" a tag. > Browsers already load all tags and attributes they encounter into the > page DOM today , regardless if they "know" them or not. This is also > the behavior that HTML5 demands, if I'm not mistaken. I have just put a sample file together, and checked it on what I have available: On Dreamweaver (CS3) and FF3, it is rendered perfectly. On IE7 and Microsoft's Visual Web Developer 2008 Express SP1, it ungracefully degrades, as I expected: they ignore the entire tag, so neither the default styles defined for the tag nor the specific classes are displayed. I also included title attributes, for fancy tooltip effects, and they show perfectly on FF; IE of course doesn't show them because they are part of the ignored tag. And, of course, both authoring tools make a mention of not being valid... but that was something that could be expected :P I tried to test this on IE8beta2, but the instalation is failing ¬¬'. Would MS be so kind to do something that doesn't break? Thanks. Sarcasms aside, if somebody wants to give this sample a try on other browsers, I've put it online at http://herenvardo.googlepages.com/test.html. Note that I have deliberatelly abused of styling to make the result stand out (ie: to easily see whether it works or not). Use your browser's "View source" features to get an idea of what to expect. >>Standards that have tried to make changes like that -- XHTML2 comes to >>mind -- have not been as successful as HTML4 [...] > > We can't really make any statements about how successful XHTML2 would > be on the public web. It's not yet a recommendation (though this would > probably not change much) and no browser implemented it, so there was > never opportunity to find out. And even so it's being used sporadically :P In addition, this case can't be compared with XHTML2: it'd give the authors a choice, since and similar elements would still be supported, for backwards compatibility. > But anyway, this discussion is moot, since many of those tags can't be > changed due to backwards compatibility. Actually, it isn't: doesn't need to be kept more than of do for the compatibility issue. The spec needs to define how to handle all of those anyway; but it isn't really tied on what does it define as "conformant" and "non-conformant". Now, going back to Pentasis's actual concern: authoring content in a way that makes sense. Just go ahead: it seems that browsers that deal with "unknown" elements in an HTML5-conformant way will handle it properly, as long as you provide some rendering info in your style-sheets. You don't really need this spec to "define" that element, as long as it works on browsers; and the spec will still require browsers to process it in a reasonable way (ie: include in the DOM, apply relevant styles, and hopefully even apply global attribs like @class or @title). So, essentially, including an element like or not is, from the browser's viewpoint, irrelevant: their required behavior will be exactly the same either way. On the author's side, it will only be relevant for authors that care about conformity and need the element, in which case it will be good to have it available. Of course, it requires a bit of extra work by the WG, to describe it in the spec (what would it be, one paragraph?). Validators may face some extra work, but I don't think anyone with a bit of sanity left would hardcode each element in the validators, but instead use some DTD-like description of the syntax and/or content model, so it isn't really that much work. And finally, on the assistive technologies' and search engines' side, this kind of elements would allow to describe the contents of webpages far better, which would be a clear benefit. So, in summary, there are some benefits for including this kind of elements; and there is any relevant backward (just a bit of extra, trivial work for spec and validator writters). Some benefits, and no *real* issues, the only plausible reason to not include this would be a desire to hurt the web (which, BTW, some XHTML2 evangelists out there think is the only goal of the WG). Can somebody put forward any technical argument against this idea? If somebody does, I'd be glad to discuss them seriously; but please think if what you're going to say at least makes sense: don't come up with the "implementation issue" (the inclusion of this kind of elements wouldn't require from implementations anything that the spec doesn't already require) or the "backwards compatibility thing" (the inclusion of new element never affects how other elements should be treated); I've better things to spend my time on than needlessly looping and replying to the s
Re: [whatwg] SPOOFED: Re: SPOOFED: Re: ---
On Wed, Nov 5, 2008 at 4:00 PM, Leons Petrazickis <[EMAIL PROTECTED]> wrote: > It matters in the sense that web browsers would have to implement both > approaches for backwards compatibility. > This depends what you mean when talking about "implementing" a tag. Browsers already load all tags and attributes they encounter into the page DOM today , regardless if they "know" them or not. This is also the behavior that HTML5 demands, if I'm not mistaken. Interactive elements and "special" elements like "script", "head", "table", etc do need further special treatment, but so far browsers seem to do little more with semantic elements than apply a default style to them. And sice CSS selectors have already widespread support as well, this behavior would be trivially repeatable for new tags by web authors themselves. So there is not that much of an implementation burden at the moment. >Standards that have tried to make changes like that -- XHTML2 comes to >mind -- have not been as successful as HTML4 [...] We can't really make any statements about how successful XHTML2 would be on the public web. It's not yet a recommendation (though this would probably not change much) and no browser implemented it, so there was never opportunity to find out. >Adoption and usability are the twin goals -- not purity or >consistency. Of course I fully agree that purity must not the only goal itself. The W3C definitely went overboard with this in their latest proposals. However, sometimes it does look as if the WHATWG takes it to the opposite extreme and treat purity and consistency as explicit non-goals. If consistency hampers usabillity, usabillity is of course to be preferred. However, I think, often the two are interrelated instead of opposing goals. After all, each inconsistency is a new rule that implementors have to implement and authors have to learn. This makes the language harder to understand and actually slows down adaption. Look at XML for the opposite story. Many people have frowned at the mass of XML-based languages, formats and specifications that popped up. But then again, why DID so many people create XML formats so quickly? Because the concept of "nested tags with attributes" is really simple to understand. Of course HTML5 has to cope with really horrible legacy content and many inconsistencies are just there. But we should still try not to introduce more. And yes, I do believe would be easier, because then web authors wouldn't need to remember which semantic content can be described by tags and which needs custom classes. But anyway, this discussion is moot, since many of those tags can't be changed due to backwards compatibility. Maybe someone should clarify though how agents are supposed to use those semantic tags, especially semantic, user-defined classes. What actual benefit do I have if I use class="heading" instead of class="style15"?
Re: [whatwg] SPOOFED: Re: SPOOFED: Re: ---
This would only work in new browsers and is wordy: someword. It doesn't add any extra information. It's harder to use. Conceptually, it may be more elegant, but conceptual elegance is not an impetus for large scale adoptions. In my opinion, it is not a worthwhile change to pursue, when there are so many actively broken issues that can be fixed. True, it doesn't provide any extra information, and perhaps it is harder to use, but that is not the point. The point is that this tag can be used to mark up any possible reference-type word (notes, sidenotes, footnotes, translations, meanings, definitiones, you name all of them and then some). So with just one tag, I catch all possible semantics within a classified wordgroup. That (or something similar) is what creates room for natural growth and evolution of contextual semantics on a medium (Internet) that is still developing and very dynamic. Bert
Re: [whatwg] SPOOFED: Re: SPOOFED: Re: ---
On Wed, Nov 5, 2008 at 6:29 AM, Pentasis <[EMAIL PROTECTED]> wrote: >> I am not sure whether I understand you correctly... Of course the >> practical use of a specification lies in its technical implementations, or >> do you disagree with that? You are free to specify your own markup language, >> but it will be useless if there is no kind of mechanism to interpret the >> documents marked up that way. So I don't understand how the technical side >> could be split away. > > Strictly speaking, does it matter for the DOM or parser or whatever, if a > tag is named and used like: someword or > like this: > someword. > I don't see how that would make things technically different? > The same applies for the difference in (for example) blabla or > blabla. It matters in the sense that web browsers would have to implement both approaches for backwards compatibility. Web site developers would then be given a choice between a succinct approach that works in all browsers and a verbose approach that only works in the newer ones. Given such a choice, web site developers mostly prefer brevity and compatibility, especially when working for a client. Any change that tries to replace an existing feature with a more complicated feature will likely not be adopted de facto, even if it is enshrined in a de jure standard. Standards that have tried to make changes like that -- XHTML2 comes to mind -- have not been as successful as HTML4, as the loose dialect of HTML4 in use on the web. HTML5 aims to be as successful as HTML4. Adoption and usability are the twin goals -- not purity or consistency. This works everywhere and is brief: someword This would only work in new browsers and is wordy: someword. It doesn't add any extra information. It's harder to use. Conceptually, it may be more elegant, but conceptual elegance is not an impetus for large scale adoptions. In my opinion, it is not a worthwhile change to pursue, when there are so many actively broken issues that can be fixed. Regards, Leons Petrazickis http://lpetr.org/blog/
Re: [whatwg] SPOOFED: Re: SPOOFED: Re: ---
Pentasis schrieb: This I understand, and I can even sympathise with it. However, I do hope that at least "they" will take this issue seriously and at least try to build in something that will enable "us" to work on that part of the spec independantly later on. I still think that the semantic part has very, very little to do with the technical side of the spec. so somewhere the two should be able to split up. I am not sure whether I understand you correctly... Of course the practical use of a specification lies in its technical implementations, or do you disagree with that? You are free to specify your own markup language, but it will be useless if there is no kind of mechanism to interpret the documents marked up that way. So I don't understand how the technical side could be split away. Strictly speaking, does it matter for the DOM or parser or whatever, if a tag is named and used like: someword or like this: someword. I don't see how that would make things technically different? The same applies for the difference in (for example) blabla or blabla. Obviously there are constructs thinkable where the two would indeed at least rub shoulders like for example in nesting headers, but I am sure something like that is not a major issue and would only mean the two specs need to come to agreement with somethings like that. Another example (just a thought, don't take it seriously) What if we eliminate headers alltogether and specify that the title attribute of a section is the header. Now, in that case I agree one should colaborate with the technical department. But in the grand scheme of things, those are minor points surely? Bert
