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
