Comment by markasoftware
1 day ago
if the world was all XHTML, then you wouldn't put an ad on your site that wasn't valid XHTML, the same way you wouldn't import a python library that's not valid python.
1 day ago
if the world was all XHTML, then you wouldn't put an ad on your site that wasn't valid XHTML, the same way you wouldn't import a python library that's not valid python.
>, then you wouldn't put an ad on your site that wasn't valid XHTML,
You're overlooking how incentives and motivations work. The gp (and their employer) wants to integrate the advertisement snippet -- even with broken XHTML -- because they receive money for it.
The semantic data ("advertiser's message") is more important than the format ("purity of perfect XHTML").
Same incentives would happen with a jobs listing website like Monster.com. Consider that it currently has lots of red errors with incorrect HTML: https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.monster.c...
If there was a hypothetical browser that refused to load that Monster.com webpage full of errors because it's for the users' own good and the "good of the ecosystem"... the websurfers would perceive that web browser as user-hostile and would choose another browser that would be forgiving of those errors and just load the page. Job hunters care more about the raw data of the actual job listings so they can get a paycheck rather than invalid <style> tags nested inside <div> tags.
Those situations above are a different category (semantic_content-overrides-fileformatsyntax) than a developer trying to import a Python library with invalid syntax (fileformatsyntax-Is-The-Semantic_Content).
EDIT reply to: >Make the advertisement block an iframe [...] If the advertiser delivers invalid XHTML code, only the advertisement won't render.
You're proposing a "technical solution" to avoid errors instead of a "business solution" to achieve a desired monetary objective. To re-iterate, they want to render the invalid XHTML code so your idea to just not render it is the opposite of the goal.
In other words, if rendering imperfect-HTML helps the business goal more than blanking out invalid XHTML in an iframe, that means HTML "wins" in the marketplace of ideas.
If xhtml really took off, there would just be server side linting/html tidy. Its not that hard a problem to solve. Lots of websites already do this for user generated html, because even if an unclosed div doesnt take down the whole thing its still ugly.
The real problem is the benefits of xhtml are largely imaginary so there isn't really a motivation to do that work.
Or you just wouldn't create xhtml with string interpolation.
> You're overlooking how incentives and motivations work. The gp (and their employer) wants to integrate the advertisement snippet -- even with broken XHTML -- because they receive money for it.
Make the advertisement block an iframe with the src attribute set to the advertiser's URL. If the advertiser delivers invalid XHTML code, only the advertisement won't render.
But all it takes in that world is for a single browser vendor to decide - hey, we will even render broken XHTML, because we would rather show something than nothing - and you’re back to square one.
I know which I, as a user, would prefer. I want to use a browser which lets me see the website, not just a parse error. I don’t care if the code is correct.
In practice things like that did happen, though. e.g. this story of someone's website displaying user-generated content with a character outside their declared character set: https://web.archive.org/web/20060420051806/http://diveintoma...
Yes, you would be able to put an ad on your site that wasn't XHTML, because XHTML is just text parsed in the browser at runtime. And yes, that would fail, silently, or with a cryptic error