On Fri, 10 Aug 2012, Erik Reppen wrote:
My understanding of the general philosophy of HTML5 on the matter of
malformed HTML is that it's better to define specific rules concerning
breakage rather than overly strict rules about how to do it right in the
first place
This is incorrect. The
Ian Hickson i...@hixie.ch, 2012-09-07 04:25 +:
On Fri, 10 Aug 2012, Erik Reppen wrote:
Why can't we set stricter rules that cause rendering to cease or at least a
non-interpreter-halting error to be thrown by browsers when the HTML is
broken from a nesting/XML-strict-tag-closing
Kang-Hao (Kenny) Lu-4 wrote:
Yep. I would encourage you to play with XHTML5 (application/xhtml+xml)
more and report bugs to browsers. When I still had interest in
application/xhtml+xml (back in 2007?), I got troubled by all the
differences in the DOM APIs. I think currently most JS
That spells out a major browser vendor issue much more clearly. I think
just having the option to develop in application/xhtml+xml and switching to
text/html is a good start though.
On Sat, Aug 11, 2012 at 10:17 AM, Karl Dubost ka...@opera.com wrote:
Le 10 août 2012 à 20:19, Tab Atkins Jr. a
Le 10 août 2012 à 20:19, Tab Atkins Jr. a écrit :
I don't wish to spend the time to dig up the studies showing that 95% or so
of XML served as text/html is invalid XML
That doesn't really makes sense, but I guess what Tab meant is
People attempting to write documents
* with XML syntax rules
My understanding of the general philosophy of HTML5 on the matter of
malformed HTML is that it's better to define specific rules concerning
breakage rather than overly strict rules about how to do it right in the
first place but this is really starting to create pain-points in
development.
Modern
On Fri, Aug 10, 2012 at 12:45 PM, Erik Reppen erik.rep...@gmail.com wrote:
My understanding of the general philosophy of HTML5 on the matter of
malformed HTML is that it's better to define specific rules concerning
breakage rather than overly strict rules about how to do it right in the
first
This confuses me. Why does it matter that other documents wouldn't work if
you changed the parsing rules they were defined with to stricter versions?
As far as backwards compatibility, if a strict-defined set of HTML would
also work in a less strict context, what could it possibly matter? It's
On Fri, Aug 10, 2012 at 3:29 PM, Erik Reppen erik.rep...@gmail.com wrote:
This confuses me. Why does it matter that other documents wouldn't work if
you changed the parsing rules they were defined with to stricter versions?
As far as backwards compatibility, if a strict-defined set of HTML
Sorry if this double-posted but I think I forgot to CC the list.
Browser vendor politics I can understand but if we're going to talk about
what history shows about people like myself suggesting features we can't
actually support I'd like to see some studies that contradict the
experiences I've
On Fri, Aug 10, 2012 at 5:02 PM, Erik Reppen erik.rep...@gmail.com wrote:
Browser vendor politics I can understand but if we're going to talk about
what history shows about people like myself suggesting features we can't
actually support I'd like to see some studies that contradict the
Le 10/08/2012 20:06, Erik Reppen a écrit :
Sorry if this double-posted but I think I forgot to CC the list.
Browser vendor politics I can understand but if we're going to talk about
what history shows about people like myself suggesting features we can't
actually support I'd like to see some
Thanks Hugh. I had mistakenly been thinking of XHTML5 as something that
never happened rather than merely HTML5 served as XML which hadn't really
occurred to me as being a viable option. I look forward to messing with
this. This is precisely what I wanted to be able to do.
On Fri, Aug 10, 2012 at
(12/08/11 8:41), Erik Reppen wrote:
Thanks Hugh. I had mistakenly been thinking of XHTML5 as something that
never happened rather than merely HTML5 served as XML which hadn't really
occurred to me as being a viable option. I look forward to messing with
this. This is precisely what I wanted to
14 matches
Mail list logo