7 ms·

This all seems horrific. Why can't HTML be properly extended to support attribute arrays or dictionaries as values? Having a value encode a DSL is so messed up.

This all seems horrific. Why can't HTML be properly extended to support attribute arrays or dictionaries as values? Having a value encode a DSL is so messed up. This is yet more to parse... HTML keeps getting pulled in so many directions. I wish XHTML had won. It was modular, pluggable, extensible, and semantic. The last bit might have eventually made entering the search space easy for new competitors, too.

yuhong 12y ago
Here, don't confuse what was XHTML1 with XHTML2.
- possibilistic 12y ago
  I'm speaking more in terms of the goals the markup dialects had, irrespective of the ultimate implementation. I think we can all agree that those suffered from misguided engineering choices (bloaty XML culture). Responsive images could have been an XHTML module with a javascript implementation. The browser vendors could catch up and provide native implementations in their own time, but that would not postpone immediate usage. If it were done right, anyone could have defined a markup module/schema with parsing rules and scripting. The evolution of those extensions would have been pretty damned fast due to forking, quick vetting/optimization, etc. It would have been well timed with the recent javascript renaissance, if it had happened. It might have meant browser vendor independence at the level of the developer. HTML should really have been modular with an efficient, lightweight core spec. It should have also paid lots of attention to being semantic so that others could compete with Google on search. I am still curious if that's why Google got involved in the WHATWG. I'm rambling about things I don't know about though...
  - domenicd 12y ago
    > Responsive images could have been an XHTML module with a javascript implementation. The browser vendors could catch up and provide native implementations in their own time, but that would not postpone immediate usage. This is exactly what happened, except without the XHTML nonsense. JavaScript polyfills of the picture element were created and in use before native implementations eventually caught up. (And native implementations are very necessary, in this case, because they need to hook in to the preload scanner, which is not JS-exposed.) More generally, custom elements and extensible web principles in general enable all of this. Again, without XML being involved.
idlewords 12y ago
XML Parsing Failed
- insertnickname 12y ago
  I really hate when my code doesn't compile. If my code is wrong, the compiler should just figure out what to do.
  - possibilistic 12y ago
    You hit the nail on the head. HTML5 got one thing right though: standardization of the DOM failure behavior. As an implementation detail of their design, they went with "sensible recovery" for failures over stricter failure modes. In going with the WHATWG over the W3C, we ultimately chose "easy to author, (slow to evolve) living standard" over "strictly typed yet developer extensible". I was disappointed, but it's good for some parties I suppose. (It certainly keeps the browser vendors in charge of the core tech...) The W3C over-engineered to a fault. They had a lot of the right ideas, but were too enamored by XML and RDF.
    - yuhong 12y ago
      HTML5 got one thing right though: standardization of the DOM failure behavior. As an implementation detail of their design, they went with "sensible recovery" for failures over stricter failure modes. It was browsers that did that in the first place. HTML5 just standardized the exact behavior on failures.
      - possibilistic 12y ago
        Which is what I said, right? HTML 4 - vendors implemented the spec incongruently and failed in their own special ways. XHTML strict - standard parsing rules with strict failure mode. HTML 5 - standard parsing rules, suggested (but not required) rendering behavior for browser uniformity, and well-defined failure behavior.
      - domenicd 12y ago
pjmlp 12y ago
Fully agree. XHTML was a sane way to have a proper application development model, instead of this document as applications hack. But the browser vendors failed to make a stand against bad HTML.
- disjointrevelry 12y ago
  'bad HTML' could easily have just been an ego clash and pissing contest between developers of competing browsers. It was arguably more difficult to implement than just well-structured syntax.
iopq 12y ago
this is why attributes are really a stupid ass way to do things <img> <srcset> <source><width>1024</width><src>large-image.jpg</source> <source><width>512</width><src>small-image.jpg</source> </srcset> <src>image.jpg</src> <*>fallback</*> <alt>My image</alt> </img>
- hrktb 12y ago
  But now it's a PITA properly handle and escape for any toolset that don't have good xml support. Imagine people starting to put <![CDATA[ ]] blocks into this.
  - iopq 12y ago
    I meant if I had designed it from the start. Then everything is a tag, no attributes, no quotes, equal signs, etc.
    - johnlbevan2 12y ago
      How about JsonML; i.e. XHTML but in JSON format to make it less verbose / further improve integration with javascript?
      - yoklov 12y ago
        You'd want to kill yourself pretty quickly. JSON is great as an interchange format, but there are many reasons editing it by hand is painful, lack of comments and lack of newlines in strings not being the least of them.
      - mckamey 12y ago
        JsonML is pretty efficient when auto-generated from HTML source. I use it as an intermediate form for client side templates ( http://duelengine.org http://duelengine.org ) but I don't write it by hand. Its regularity makes it a perfect candidate for output from a parser/compiler.
    - aubergene 12y ago

yuhong 12y ago

Here, don't confuse what was XHTML1 with XHTML2.

possibilistic 12y ago
I'm speaking more in terms of the goals the markup dialects had, irrespective of the ultimate implementation. I think we can all agree that those suffered from misguided engineering choices (bloaty XML culture). Responsive images could have been an XHTML module with a javascript implementation. The browser vendors could catch up and provide native implementations in their own time, but that would not postpone immediate usage. If it were done right, anyone could have defined a markup module/schema with parsing rules and scripting. The evolution of those extensions would have been pretty damned fast due to forking, quick vetting/optimization, etc. It would have been well timed with the recent javascript renaissance, if it had happened. It might have meant browser vendor independence at the level of the developer. HTML should really have been modular with an efficient, lightweight core spec. It should have also paid lots of attention to being semantic so that others could compete with Google on search. I am still curious if that's why Google got involved in the WHATWG. I'm rambling about things I don't know about though...
- domenicd 12y ago
  > Responsive images could have been an XHTML module with a javascript implementation. The browser vendors could catch up and provide native implementations in their own time, but that would not postpone immediate usage. This is exactly what happened, except without the XHTML nonsense. JavaScript polyfills of the picture element were created and in use before native implementations eventually caught up. (And native implementations are very necessary, in this case, because they need to hook in to the preload scanner, which is not JS-exposed.) More generally, custom elements and extensible web principles in general enable all of this. Again, without XML being involved.

idlewords 12y ago

XML Parsing Failed

insertnickname 12y ago
I really hate when my code doesn't compile. If my code is wrong, the compiler should just figure out what to do.
- possibilistic 12y ago
  You hit the nail on the head. HTML5 got one thing right though: standardization of the DOM failure behavior. As an implementation detail of their design, they went with "sensible recovery" for failures over stricter failure modes. In going with the WHATWG over the W3C, we ultimately chose "easy to author, (slow to evolve) living standard" over "strictly typed yet developer extensible". I was disappointed, but it's good for some parties I suppose. (It certainly keeps the browser vendors in charge of the core tech...) The W3C over-engineered to a fault. They had a lot of the right ideas, but were too enamored by XML and RDF.
  - yuhong 12y ago
    HTML5 got one thing right though: standardization of the DOM failure behavior. As an implementation detail of their design, they went with "sensible recovery" for failures over stricter failure modes. It was browsers that did that in the first place. HTML5 just standardized the exact behavior on failures.
    - possibilistic 12y ago
      Which is what I said, right? HTML 4 - vendors implemented the spec incongruently and failed in their own special ways. XHTML strict - standard parsing rules with strict failure mode. HTML 5 - standard parsing rules, suggested (but not required) rendering behavior for browser uniformity, and well-defined failure behavior.
    - domenicd 12y ago

pjmlp 12y ago

Fully agree. XHTML was a sane way to have a proper application development model, instead of this document as applications hack. But the browser vendors failed to make a stand against bad HTML.

disjointrevelry 12y ago
'bad HTML' could easily have just been an ego clash and pissing contest between developers of competing browsers. It was arguably more difficult to implement than just well-structured syntax.

iopq 12y ago

this is why attributes are really a stupid ass way to do things <img> <srcset> <source><width>1024</width><src>large-image.jpg</source> <source><width>512</width><src>small-image.jpg</source> </srcset> <src>image.jpg</src> <*>fallback</*> <alt>My image</alt> </img>

hrktb 12y ago
But now it's a PITA properly handle and escape for any toolset that don't have good xml support. Imagine people starting to put <![CDATA[ ]] blocks into this.
- iopq 12y ago
  I meant if I had designed it from the start. Then everything is a tag, no attributes, no quotes, equal signs, etc.
  - johnlbevan2 12y ago
    How about JsonML; i.e. XHTML but in JSON format to make it less verbose / further improve integration with javascript?
    - yoklov 12y ago
      You'd want to kill yourself pretty quickly. JSON is great as an interchange format, but there are many reasons editing it by hand is painful, lack of comments and lack of newlines in strings not being the least of them.
    - mckamey 12y ago
      JsonML is pretty efficient when auto-generated from HTML source. I use it as an intermediate form for client side templates ( http://duelengine.org http://duelengine.org ) but I don't write it by hand. Its regularity makes it a perfect candidate for output from a parser/compiler.
  - aubergene 12y ago