2 ms·

Yes, actually it would be. Tell me, what do you think is the advantage of inventing some random meaning for what is declared to be an HTML document but actuall

Yes, actually it would be. Tell me, what do you think is the advantage of inventing some random meaning for what is declared to be an HTML document but actually isn't (bonus: that would not equally apply to code in a programming language)?

eridius 9y ago
First off, nobody has ever said you should "invent some random meaning" for anything. Secondly, it's pretty obvious what the benefit is of doing the best job you can rendering a document that contains some error in part of it. The existence of an error in one section of a document shouldn't have any impact on the rest of the document, and so there's no reason why the error should prevent rendering the rest of the document.
- schoen 9y ago
  It seems like you two are arguing over whether or not it's important for documents to have formal semantics. If documents need to have formal semantics, then syntactic errors could be considered fatal because they create ambiguity. If documents don't need to have formal semantics, then you can ignore syntactic errors and accept that an ambiguity was present and was resolved arbitrarily. It seems like both views are quite defensible, depending on your theory of what the markup was meant for.
  - zAy0LfpBZLC8mAC 9y ago
    Well, no, actually the view is not defensible, because it insists on the arbitrary resolution being an implementation of a standard, which it isn't. The view formulated in a non-misleading way is simply "if the standard does not specify semantics, I can as a matter of fact just use my own proprietary interpretation instead". Which is trivially true, but also completely useless if your goal is interoperability, while, if you don't care about interoperability, why care about the standard in the first place?
    - inimino 9y ago
      People write software. Standards come later. Your standards zealotry is blinding you to how software development gets done and how the Web really works. You are calling "indefensible" the way the entire industry actually works. Maybe you want to step back and look at why that happens.
      - zAy0LfpBZLC8mAC 9y ago
        1. Which prevents people from fixing their software to conform to the standards once they exist how exactly? 2. What is even your point? That the industry has an outstanding track record of interoperability and security? What exactly is it that makes the view defensible in your eyes?
        inimino 9y ago
        1. See the entire history of the Web so far. Obviously the observation about browser market share and "Don't break the Web" has been made many times, I am not going to rehash it for you here. 2. Standards are a tool to improve interoperability. When standards are disconnected from reality and cannot be implemented by any actual players in the market, interoperability is harmed. It is not even neutral. The kind of attitude you are showing here is what got us the idiocy of XHTML2. That is, many of the people who cared most about standards and semantics on the Web went and threw their collective efforts into a black hole for years because they were too blindly idealistic to engage with or even acknowledge the actual industry, that, in their arrogance, they thought they were standardizing. Meanwhile everyone else happily ignored them and all their efforts had no real-world impact on anything, except that by taking attention away from other, more realistic, standardization efforts, they probably set real interoperability back several years.
        zAy0LfpBZLC8mAC 9y ago
        Which is all completely besides the point? Reverse engineering and reimplementing the semantics of another vendor is obviously very much the opposite of "inventing random meaning", but rather "implementing a de-facto standard", and as such obviously helps interoperability. But that in no way justifies the first vendor inventing that de-facto standard in the first place, whithout wich there would be no need for anyone to reverse-engineer and reimplement it. If all deviations by browser implementors from the formal standard were reimplementations of deviations by other vendors for the sake of better interoperability ... there would not be any deviations at all.
- zAy0LfpBZLC8mAC 9y ago
  > First off, nobody has ever said you should "invent some random meaning" for anything. Well, yes, you have. The definition of an error in this context is that there is no meaning for the given syntax specified in the standard. If you interpret the document anyway, you are assigning it some meaning. As that meaning does not come from the standard, you have simply invented it. > The existence of an error in one section of a document shouldn't have any impact on the rest of the document, and so there's no reason why the error should prevent rendering the rest of the document. 1. You have it all backwards. Whether something is a "section" is part of the semantics that are specified by the standard. When your document does not comply to the standard, the standard does not assign any semantics to it, and as such it also does not specify what a section is in your non-complying document. The moment you talk about "sections" in your non-HTML document, say, you have already started inventing semantics. Also, even if we assume that we somehow can magically identify "sections" anyway: How do you justify the assumption that sections do not have any impact on one another? For one, if you take HTML, in particular when CSS is involved, you absolutely easily can have very global effects using rather local constructs, can't you? But also: What if the human-language content has cross-references between sections? How do you ensure that the meaning of the human-readable content is conveyed correctly when somehow processing a "broken section"? What if the result is that you leave out an important warning regarding the following instructions in an attempt to help the user? Really, how is that any different from a compiler replacing functions with errors with a No-Op? 2. What is the actual advantage? You say it is obvious, but it's not to me, which is why I asked. What is the advantage of just displaying something, even if the standard does not assign it any meaning, over aborting with an error?
- kazinator 9y ago
  Doing "the best" by inventing some way to continue in the face of an error has caused nothing but grievous harm to the world wide web. The developer of the HTML markup must not rely on the browser doing "its best" with bad HTML. During development, it's helpful if the implementation finds as many errors as possible in one pass and flags them all. Whether or not anything is rendered is immaterial; the HTML writer should fix everything. The end user shouldn't see any errors, because they all blew up in the HTML writer's face and were fixed. It is a fact that rendering happens in parallel with downloading a web page. So yes, renderers should be able to render a prefix of a web page, up to the first error, because the situation is entirely possible that only that prefix has been downloaded and the error is not yet seen. Renderers should not delay rendering until the entire page is seen; something has to be rendered when the prefix is available, but the erroneous text which immediately follows has not yet been seen. Beyond that, no. Stop at the first error and splash a big red diagnostic into the output, so the user can see that the HTML producer screwed up.
kazinator 9y ago
Why, the advantage is that if your browser has a big market share, then many web developers out there declare their job to be done when their HTML looks fine on your browser. Then when the HTML is tried with other browsers, it looks like crap. So then the advantage is that it looks like other browsers trying to compete with yours are crap. The competing web browsers developers are unhappy and grumble a lot, but in the end have no choice by to try to emulate the random meaning that you have assigned to the HTML. Of course, you haven't publicly documented it, so they have to spend time reverse-engineering it, which means they will be perpetually lagging behind.

eridius 9y ago

First off, nobody has ever said you should "invent some random meaning" for anything. Secondly, it's pretty obvious what the benefit is of doing the best job you can rendering a document that contains some error in part of it. The existence of an error in one section of a document shouldn't have any impact on the rest of the document, and so there's no reason why the error should prevent rendering the rest of the document.

schoen 9y ago
It seems like you two are arguing over whether or not it's important for documents to have formal semantics. If documents need to have formal semantics, then syntactic errors could be considered fatal because they create ambiguity. If documents don't need to have formal semantics, then you can ignore syntactic errors and accept that an ambiguity was present and was resolved arbitrarily. It seems like both views are quite defensible, depending on your theory of what the markup was meant for.
- zAy0LfpBZLC8mAC 9y ago
  Well, no, actually the view is not defensible, because it insists on the arbitrary resolution being an implementation of a standard, which it isn't. The view formulated in a non-misleading way is simply "if the standard does not specify semantics, I can as a matter of fact just use my own proprietary interpretation instead". Which is trivially true, but also completely useless if your goal is interoperability, while, if you don't care about interoperability, why care about the standard in the first place?
  - inimino 9y ago
    People write software. Standards come later. Your standards zealotry is blinding you to how software development gets done and how the Web really works. You are calling "indefensible" the way the entire industry actually works. Maybe you want to step back and look at why that happens.
    - zAy0LfpBZLC8mAC 9y ago
      1. Which prevents people from fixing their software to conform to the standards once they exist how exactly? 2. What is even your point? That the industry has an outstanding track record of interoperability and security? What exactly is it that makes the view defensible in your eyes?
      - inimino 9y ago
        1. See the entire history of the Web so far. Obviously the observation about browser market share and "Don't break the Web" has been made many times, I am not going to rehash it for you here. 2. Standards are a tool to improve interoperability. When standards are disconnected from reality and cannot be implemented by any actual players in the market, interoperability is harmed. It is not even neutral. The kind of attitude you are showing here is what got us the idiocy of XHTML2. That is, many of the people who cared most about standards and semantics on the Web went and threw their collective efforts into a black hole for years because they were too blindly idealistic to engage with or even acknowledge the actual industry, that, in their arrogance, they thought they were standardizing. Meanwhile everyone else happily ignored them and all their efforts had no real-world impact on anything, except that by taking attention away from other, more realistic, standardization efforts, they probably set real interoperability back several years.
        zAy0LfpBZLC8mAC 9y ago
        Which is all completely besides the point? Reverse engineering and reimplementing the semantics of another vendor is obviously very much the opposite of "inventing random meaning", but rather "implementing a de-facto standard", and as such obviously helps interoperability. But that in no way justifies the first vendor inventing that de-facto standard in the first place, whithout wich there would be no need for anyone to reverse-engineer and reimplement it. If all deviations by browser implementors from the formal standard were reimplementations of deviations by other vendors for the sake of better interoperability ... there would not be any deviations at all.
zAy0LfpBZLC8mAC 9y ago
> First off, nobody has ever said you should "invent some random meaning" for anything. Well, yes, you have. The definition of an error in this context is that there is no meaning for the given syntax specified in the standard. If you interpret the document anyway, you are assigning it some meaning. As that meaning does not come from the standard, you have simply invented it. > The existence of an error in one section of a document shouldn't have any impact on the rest of the document, and so there's no reason why the error should prevent rendering the rest of the document. 1. You have it all backwards. Whether something is a "section" is part of the semantics that are specified by the standard. When your document does not comply to the standard, the standard does not assign any semantics to it, and as such it also does not specify what a section is in your non-complying document. The moment you talk about "sections" in your non-HTML document, say, you have already started inventing semantics. Also, even if we assume that we somehow can magically identify "sections" anyway: How do you justify the assumption that sections do not have any impact on one another? For one, if you take HTML, in particular when CSS is involved, you absolutely easily can have very global effects using rather local constructs, can't you? But also: What if the human-language content has cross-references between sections? How do you ensure that the meaning of the human-readable content is conveyed correctly when somehow processing a "broken section"? What if the result is that you leave out an important warning regarding the following instructions in an attempt to help the user? Really, how is that any different from a compiler replacing functions with errors with a No-Op? 2. What is the actual advantage? You say it is obvious, but it's not to me, which is why I asked. What is the advantage of just displaying something, even if the standard does not assign it any meaning, over aborting with an error?
kazinator 9y ago
Doing "the best" by inventing some way to continue in the face of an error has caused nothing but grievous harm to the world wide web. The developer of the HTML markup must not rely on the browser doing "its best" with bad HTML. During development, it's helpful if the implementation finds as many errors as possible in one pass and flags them all. Whether or not anything is rendered is immaterial; the HTML writer should fix everything. The end user shouldn't see any errors, because they all blew up in the HTML writer's face and were fixed. It is a fact that rendering happens in parallel with downloading a web page. So yes, renderers should be able to render a prefix of a web page, up to the first error, because the situation is entirely possible that only that prefix has been downloaded and the error is not yet seen. Renderers should not delay rendering until the entire page is seen; something has to be rendered when the prefix is available, but the erroneous text which immediately follows has not yet been seen. Beyond that, no. Stop at the first error and splash a big red diagnostic into the output, so the user can see that the HTML producer screwed up.

kazinator 9y ago

Why, the advantage is that if your browser has a big market share, then many web developers out there declare their job to be done when their HTML looks fine on your browser. Then when the HTML is tried with other browsers, it looks like crap. So then the advantage is that it looks like other browsers trying to compete with yours are crap. The competing web browsers developers are unhappy and grumble a lot, but in the end have no choice by to try to emulate the random meaning that you have assigned to the HTML. Of course, you haven't publicly documented it, so they have to spend time reverse-engineering it, which means they will be perpetually lagging behind.