[whatwg] ---

>
> The HTML5 spec is open to feedback from linguists, typographers and 
> content creators. I would agree we should particularly give  consideration 
> to people with those backgrounds with regards to issues  of semantics. On 
> the other hand, there is not total freedom here  because some choices will 
> result in conflict with Web compatibility or  with practical 
> implementation concerns.
>
> Do you have any specific concerns about the current spec? That would  be 
> more useful than criticizing the design process in the abstract.
>

I would be more than willing to do so, but only if these ideas are taken 
seriously and we can have a civil, open dicussion about it without going 
into defensive  mode or side-arguments.
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).
also, please keep in mind I am not a native english speaker. I sometimes 
have difficulty explaining exactly what I mean. If something is unclear, 
just say so.
Finally, the ideas portrait below are just that. Ideas. I don't feel 
strongly about the actual ideas themself, but I do feel strongly about the 
mechanism they represent.


The best way of explaining what I mean is by talking about the inline text 
elements, but the concept is the same for all element (apart from maybe the 
metadata group).

What the spec currently does is:
1) *exactly* defining some elements
2) Giving examples for *some* constructions whcih are not defined exactly
3) not talk about other things.

Like I have said before, the problem is that nobody can think up all 
possible type of semantic/content/context in existance (let alone those who 
are thought up).
The only solution would be by creating a type of classification methode. 
Partly this is allready there (block, inline, text, structure, etc.). But 
this should be done one more level down.

For example:

abbr, dfn, cite are all the same "type" of "word". Why not remove them and 
replace them with something like <reference> (just an example!).
Then use the class attribute to define the actual role (class="abbreviation" 
etc.). In other words, implement the microformats on  a much wider base as 
part of the standard.
These classifications can then be requested and implemented outside of the 
spec in an open forum.A process which should be fast and more structurised 
than it is currently.
The same applies for em and strong. Not sure hwo these should eb classified, 
but I think they are used to change a word or group of word in context. So 
perhaps a <contxt> tag? sup and sub would also fall in this catagory 
(technically speaking sup and sub are style elements).
pre is also a style element. Why not simply use <p> and style it 
preformatted if needed depending on the role it has?

<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.

So, the general idea is to classify all all elements as high up the 
classification-tree as possible, and then allow subclassing in the 
class-attribute. Main classes would be specified in the standard, and 
sub-classes are specified in an open list which can act upon need on a 
practical basis. (I understand the need for such a list to be maintained on 
a consistent level, something like that could be defined in the standard as 
well).

Apart from this classification system I think there are other points where 
the spec could be improved, but this classification system I think is the 
most important. I understand that it is based on microformats and is not 
new, I am not claiming some new revolutionary idea here, simply trying to 
point out the advantages of doing it like that.

I will leave other ideas for later (if you want)

Bert

Received on Wednesday, 5 November 2008 00:46:19 UTC