Re: Write-up about semantics in HTML5 from A List Apart

John Allsopp wrote:
>> This runs into serious issues with DOM APIs.  For example, if a 
>> @structure can be tossed on to any element, and having 
>> structur="header" implies some sort of DOM API (e.g. getting the 
>> heading level), then all HTML elements have to expose this DOM API.
>>  This leads to all sorts of methods and properties floating around
>> that at best do nothing most of the time until some magic
>> attributes are set.
> 
> I didn't at all take  browser implementers perspective when putting 
> forward the suggestion - for a couple of reasons

None of that was from an implementation POV.  It was from an authoring
POV.  Having methods that sometimes magically do something and sometimes
don't is really confusing from an authoring perspective.

There is also specification complexity.  For example, describing the
behavior of <input> when the type attribute changes is actually rather
nontrivial, and the different input types are a lot more similar to each
other semantically than most things would be in your proposal if I
understood it correctly.

> 2. I actually don't think issues of browser performance and
> complexity (as opposed to something being impossible) should come
> into these decisions.

That depends on whether you want your proposals to be implemented quickly.

More to the point, very little is "impossible".  It's all just code.
Short of things that are provably impossible under certain assumptions
(and you'd better be very sure they were assumptions that actually make
sense), there are a great many things that are possible but
prohibitively expensive in terms of programmer time, cpu time, memory
usage, disk usage, mental overhead (making it a practical impossibility
until the development of transhuman AI), or all of the above.

> We are developing communications solutions for the timeframe of
> decades.

While true, a solution that is always a decade away is not much use,
though.  So whether this state of being targeted at the future is
permanent or temporary is something that definitely needs to be kept in
mind.

I'm also not sure why IE6/7 compat (an important part of the motivation 
for your proposal, as I understand) is more important for a solution 
with a decades-long timeframe than ease of implementation in future 
browsers and ease of authoring by future authors.

>> It also means that implementation is complicated because semantics
>> can change on the fly via setAttribute.  I view this as highly
>> undesirable.
> 
> Lot's of things can already change on the fly (event handling, style)
> in such away - are they similarly undesirable?

No, because those are conceptually distinct from the element and aren't
stored as part of the element itself, I would think.  The semantics of
the element, on the other hand, are what the element "is" in any real sense.

One could switch to a setup like XUL in Gecko where the element itself
is just a thin wrapper and any actual functionality that implements any
semantics lives elsewhere (some sort of object, layout data structures,
whatever).  I can guarantee that this increases implementation
complexity (based on our experience in Gecko; we're trying to move away
from this model as much as we can).

> Thanks for the thoughts, and for emailing me directly!

No problem!

-Boris

Received on Tuesday, 6 January 2009 23:02:33 UTC