That way, you could legally server the
same content as both HTML and XHTML. (You can do that now, but it won't
validate as HTML which is a drag. If you want to be able to serve the
same content as both HTML and XHTML, you would want to make sure that it
validates as both HTML and XHTML.)
regards
Olav Junker KjÃr
n
(except that "children" includes comments). I agree that this is useful.
"parentElement" would always be the same as "parentNode" though, won't it?
regards
Olav Junker KjÃr
tools should be allowed to check this adherence using
various methods, the same way that different browsers (presumably) uses
different parsers to parse the document.
Olav Junker KjÃr
TD.
> A user agent *must not* be automatically non-conformant for doing it's
> job correctly!!!
A user agent which only supports some small parts of the spec should not
claim to be compliant with the spec.
regards
Olav Junker KjÃr
Lachlan Hunt wrote:
Because, if I am understanding correctly and a validator is a form of
conformance checker, a validator cannot check constraints that are not
expressed in the DTD and require them to be interpreted by the author.
Therefore, validators are exempt from checking such constraints,
e that "valid" would mean "valid according to the
spec".
regards
Olav Junker KjÃr
anged.
An innocent question (no flamewar intended): What is the benefit of
having HTML defined as an application of SGML ?
regards
Olav Junker KjÃr
ly
user-empowering by default, independently from the decision to support WF2.
(BTW. I don't really understand why its user-hostile not to cache
sensitive info by default, it seems quite sensible to me. But I
understand that a spec shouldn't needlessly constrain UI.)
regards
Olav Junker KjÃr
11.3) also seem to
assume that focus is a propery of the document rather than the viewport.
Again I think its more correct to have it a property of the viewport.
regards
Olav Junker KjÃr
Matthew Raymond wrote:
In general, if you set a DOM property, it won't set the actual
attribute in markup. In order to change the markup, I think you have to
use the setAttribute method. However, I believe that the setAttribute
method does change the DOM property.
Did a quick test: In Mozilla
gets rather
complicated.
It does make sense though, to standardize the execCommand interface,
since lots of CMS frontends rely on contentEditable+execCommand, and
this is an area where IE have a stronghold, since its still the only
browser (as far as I know) that support contentEditable.
regards
Olav Junker KjÃr
field does change the DOM "value"
attribute, but does not change the "value" content attribute in the
underlying HTML.
regards
Olav Junker KjÃr
ince
> dealing with selections within controls is more common.
But one interface is simpler that two interfaces, and we need DOM Range
(or something similar) anyway to do rich editing, which is arguably just
as common an use case.
regards
Olav Junker KjÃr
d for handling editing in form controls and in elements
with contentEditable.
Olav Junker KjÃr
it's the contents of the value attribute that is
edited, rather than the element contents. But it would probably be a
mess to try to change now.
Olav Junker KjÃr
the contents of an element is made directly
editable.
Olav Junker KjÃr
16 matches
Mail list logo
