5 ms·

> it definitely is unreasonably burdensome to create XML Disagree. You open the tag, you close it. Nested. I worked with a non-developer who had some KML (http

> it definitely is unreasonably burdensome to create XML Disagree. You open the tag, you close it. Nested. I worked with a non-developer who had some KML (https://developers.google.com/kml/ https://developers.google.com/kml/) dumped on her without any training whatsoever and when I explained a few basic thing, including the above rule, she got the principle of it in a few minutes. Because it's not hard (although dumping a KML task on a non-dev is a bastard thing to do). > but people weren't using XML editors I personally think that lowering the bar to let as many people in as possible isn't necessarily a good idea. Just IMO

jefftk 7y ago
I agree the approach sounds reasonable, and I think if we were having this conversation twenty years ago I would have been on the pro-XHTML side. But we tried it, and it didn't work.
- pdimitar 7y ago
  Not sure I ever understood why it didn't work exactly. Do you have examples?
  - Vinnl 7y ago
    People who did try to author XHTML often inadvertently introduced the yellow screen of death, and did not feel they were getting anything in return.
  - mkozlows 7y ago
    Here's the classic Hixie write-up, from 2002: https://www.hixie.ch/advocacy/xhtml https://www.hixie.ch/advocacy/xhtml
  - goto11 7y ago
    XHTML could either be served as HTML or as XML. When served as XML it would not render in all browsers, but when served as HTML it would. Since serving as XML did not provide any particular value for the document author, there was no reason to use it. But XHTML served as HTML is just HTML with some extra slashes which are ignored.
james-skemp 7y ago
I wonder how many people think it was unreasonable due to how you had to send back the page to be truly valid; application/xhtml+xml, application/xml, or text/xml. Due to IIS, browser support, and the platforms I personally used, that was the only requirement I never felt I had to meet. I personally agree with you, and still close my tags, use quotes around attribute values, and provide empty/duplicate values when needed. I also still use XML for data storage, and used ColdFusion back in the 6/7 days, so that probably had a influence on my choices.
Finnucane 7y ago
But every editor used by web programmers has access to extensions that will manage xml.

jefftk 7y ago

I agree the approach sounds reasonable, and I think if we were having this conversation twenty years ago I would have been on the pro-XHTML side. But we tried it, and it didn't work.

pdimitar 7y ago
Not sure I ever understood why it didn't work exactly. Do you have examples?
- Vinnl 7y ago
  People who did try to author XHTML often inadvertently introduced the yellow screen of death, and did not feel they were getting anything in return.
- mkozlows 7y ago
  Here's the classic Hixie write-up, from 2002: https://www.hixie.ch/advocacy/xhtml https://www.hixie.ch/advocacy/xhtml
- goto11 7y ago
  XHTML could either be served as HTML or as XML. When served as XML it would not render in all browsers, but when served as HTML it would. Since serving as XML did not provide any particular value for the document author, there was no reason to use it. But XHTML served as HTML is just HTML with some extra slashes which are ignored.

james-skemp 7y ago

I wonder how many people think it was unreasonable due to how you had to send back the page to be truly valid; application/xhtml+xml, application/xml, or text/xml. Due to IIS, browser support, and the platforms I personally used, that was the only requirement I never felt I had to meet. I personally agree with you, and still close my tags, use quotes around attribute values, and provide empty/duplicate values when needed. I also still use XML for data storage, and used ColdFusion back in the 6/7 days, so that probably had a influence on my choices.

Finnucane 7y ago

But every editor used by web programmers has access to extensions that will manage xml.