Real solutions, semantics, and proposals of members of this WG

HI James,

On Aug 2, 2007, at 5:50 AM, James Graham wrote:

>
> Karl Dubost wrote:
>> Just to illustrate why some arguments can be misunderstood  
>> sometimes (and there are more than two sides). James it is just  
>> taken as an example, so let's not make it a personal issue.
>> Le 1 août 2007 à 06:29, James Graham a écrit :
>>> I would argue that semantics-for-the-sake-of-semantics is not  
>>> Solving Real Problems (c.f. the design principles).
>> Why this sentence is an issue?
>> It paints a black and white situation. it characterizes two camps:
>> * one as a bunch of (not realistic) academics
>> * one as a bunch of (realistic)     engineers.
>
> I assure you that wasn't the intention, although I see how you  
> could interpret it that way. I hope it will be useful to clarify my  
> (apparently poorly expressed) intent.
>
> I think there are two issues here which maybe need to be  
> disentangled: a) the cited design principle and b) the message that  
> I was actually trying to convey.
>
> We have a (draft) design principle that states:
>
> "Solve Real Problems
>
> SolveRealProblems: Changes to the spec should solve actual real- 
> world problems. Abstract architectures that don't address an  
> existing need are less favored than pragmatic solutions to problems  
> that web content faces today. And existing widespread problems  
> should be solved, when possible."
>
> Clearly, in order to apply this principle we must have some level  
> of shared understanding about what constitutes an "actual real- 
> world problem". I don't believe consensus on this issue exists as,  
> for example, Rob Burns has occasionally suggested introducing  
> elements, or retaining attributes, on the basis that they improve  
> semantics (Rob, please correct me if I have misunderstood you). I  
> do not believe that such a reason is prima facie sufficient to  
> fulfill "Solve Real Problems", rather one needs to identify an / 
> additional/ problem (beyond greater expressiveness of the language)  
> that can be solved by including a particular markup construct (or  
> rather the reverse; one needs to identify a problem and then design  
> markup that solves it). Some consensus on the correct  
> interpretation of this design principle will make applying it much  
> easier.

No, I don't think you misunderstand me. However, I do think you  
misunderstand what goes into an HTML specification. All of the  
proposals are basically what you refer to as semantics for the sake  
of semantics. They are all intended to solve real problems (even  
those that try to fix UA interpretation of semantics). The issues  
that we dispute over is whether the problems each of us want to solve  
is one worth solving. Earlier I posed the idea that we could  
introduce an element such as:

<IRONYINTHEWAYSHAKESPEAREUSEDITINTHE2NDACTOFAHMLET  
type='ashamletsaidit' >

Here this is a semantic that is so fine-grained that we could all (I  
hope) agree that we do not need it in HTML. On the other hand: EM and  
P are so often used that I think we can all agree that those are  
necessary to retain in HTML5.

Both examples solve real problems. Both are semantics for the sake of  
semantics (which is how HTML solves real world problems). Even the I  
and B elements are semantics for the sake of semantics: just look at  
how uncontroversial it is to remove TT and U and S and even FONT. We  
can remove those elements without controversy because they are purely  
presentational. I mean this in a very specific way. They are purely  
presentational in the sense that they do not constitute a  
presentational idiom for any particular semantic already handled in  
HTML. For example S typically only means one thing (I stress  
typically, ,an author could ad hoc define it to mean anything): a  
proposed deletion. However this is already handled by DEL. Underline  
can be used as a standard for several underlying semantics, but in  
every case it is already handled by another presentational element  
(such as I for a book title) or INS for proposed insertions. Also U  
is generally deprecated as a presentational idiom on computers with  
modern typographic capabilities (it was a hold over from the century  
of the typewriter).

So my point (and I think Karl's too) is that we're all trying to  
solve real world problems. Some think that other member's problems  
are unworthy of solution (or stupid or silly or out of line). This  
may be stated as your solution doesn't solve a real world problem,  
but that's just being naive. And all of these real world problems  
will be solved through the introduction of semantics (or in some  
cases through the removal of semantic facilities that perhaps caused  
confusion). That's really what we're doing here.

Does a new VIDEO (or EMQ emphatic quotation) element  solve a real  
world problem? Certainly. Is it an introduction of semantics for the  
sake of semantics? Yes. Is it something that steps over a certain  
line where we're just adding new semantic complexity without a duly  
justified need? That is the difficult and necessarily subjective  
question. To me  answering that question requires us to gather  
together all of the proposals. To build a consensus around  
prioritizing. Once we collect together all of the added elements and  
attributes and look at the big picture, only then can we discern  
whether we've made the new HTML5 language too complicated. Rejecting  
the Shakespeare element above is easy. It's all of the boundary cases  
that are hard. And I think any good faith proposal from a member of  
this WG should be considered as one of those boundary proposals.

Take care,
Rob