|
|
#16
06-01-08, 06:23 PM
|
|
|
|
|
On Jun 1, 5:31 pm, Dan Rumney <danrum> wrote:
> VK, PointedEars, > > Please don't hijack this thread to bicker about accessibility. IMHO it is not hijacking but branching on a sub-topic within the same main topic. But I have no problem with shifting to a new topic like "Javascript and accessibility" if more on the sub-topic will be posted. > It's abundantly clear that anyone using a UA that does not have > Javascript is not going to be able to access pages generated using the > model that I outlined in the original post. They will if you properly design NOSCRIPT redirect and/or warning blocks. > I think a more fruitful discussion would focus on other, less obvious > aspects, which is why I'm seeking the thoughts of others. 1) Search recents about Ruby in this group for one (the problem with script inserting script inserting ...) 2) Another one is specific for charsets above US-ASCII in Javascript strings, especially in document.write. Maybe it is not your case. 3) Browser screen update mechanics may make _very_ big delay before any content will get visible unless you are using properly context releases over setTimeout. By now and IMO it is the most common mistake made in Javascript / XHR intensive solutions. |
|
|
|
#17
06-01-08, 07:31 PM
|
|
|
|
|
Peter Michaux wrote:
> On Jun 1, 3:56 am, Thomas 'PointedEars' Lahn <PointedE> wrote: >> Peter Michaux wrote: >>> Over the past while one of my work projects has amounted to an HTML >>> page that essentially looks like this: <!DOCTYPE HTML PUBLIC >>> "-//W3C//DTD HTML 4.01 Transitional//EN" >>> "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title>one-page >>> client-side app</title> <script src="library.js" >>> type="text/javascript"></script> <script src="app.js" >>> type="text/javascript"></script> </head> <body> </body> </html> The >>> app.js file loads all the necessary data using Ajax and JSON. The >>> body is dynamically built based on this data. >> Very accessible. NOT. > > I didn't claim it to be. You claimed it to be working. Generally. > This architecture was not completely my choice. It was the result of > business requirements. That does not make the result a good one. > This page is behind a login which changes the balance of pros and cons in > the decision making. That statement is not true in itself. Even an application that requires a login could be exposed to a not so common environment. >>>> It would be a lot simpler to ensure validity of the HTML (as the >>>> final product would always be available to me). >>> I don't understand this either. It should be easy to validate the >>> HTML either way. >> As the W3C Validator documentation explains already, Validation alone >> is not a mark of service quality. An empty document, a document that >> has no content without scripting, is FUBAR. > > I know that acronym and that is simply your opinion about a subjective > topic. Diminishing an opinion by stating that the topic it discusses is subjective is fallacious because all opinions are subjective. What matters is if an opinion is well-founded or not. I think mine is, as I think I have presented conclusive non-fallacious arguments to support it in the process. > When one decides to publish information on the web only, one is requiring > a reader to have a computer, For suitable values of "computer". Computers come in different forms nowadays. > an internet connection As much as it may surprise you, it is _not_ a necessity. Content can be stored while the Internet connection is established and accessed later offline. > and web browser (or similar program to get content off the web). I can accept that as an axiom of no greater value: You need a Web user agent to access Web content. > That is setting the bar quite high High for whom? > and expensive. Not necessarily. > For a interested person without a computer the content completely > inaccessible to them. > > This establishes that the interested reader requires some set of certain > technology to access the information. In general web content is > published as HTML. Raw HTML is completely unintelligible to the majority > of readers without training in HTML. While that is true, it is entirely irrelevant to this discussion. > That means that for practical purposes, most readers require a computer, > internet connection and a web browser See above. > like Firefox or Internet Explorer. Naming examples to support an argument in an attempt to make believe that there are no other examples that could contradict the argument is another fallacy. > The point still being that a very specific set of technology is required > to access the information. But that is entirely irrelevant to this discussion. > Adding CSS, JavaScript and cookie support to this list of requirements > follows the same path of logic. A fallacious logic at that. The mere use of CSS, JavaScript or cookies does not imply a necessity for support of these features. A document can be and should be useful without CSS, client-side scripting and cookies. > If JavaScript is or is not required to access content, there is still > some describable set of requirements to access the content. You are making conclusions based on false or irrelevant premises. > To say that requiring JavaScript for a page is a mistake is a subjective > remark. Every remark is subjective. > If a publisher is willing to discard all potentially interested readers > that do not have an internet connection etc, then the publish could > subjectively decide that JavaScript is a requirement. Which does not mean in any way that this decision is a reasonable one. We are not discussing which decisions can be made but whether these decisions are justified. > The later decision about JavaScript requirement will exclude less readers > then the former decision about requiring an internet connection. Given that the latter requires the former in some way, that is a fallacy. > I cannot see how a logical person could say that I am objectively > incorrect. That is because you do not see that your argumentation is filled with fallacies. > It has become quite clear over my time reading comp.lang.javascript that > you believe you know the right way to do things At least I can *justify* my design decisions. > and that anyone else doing it different is not just wrong but also an > idiot. It may be *your* impression, but that does not constitute evidence that it is objectively true. BTW, such ad-hominem attacks, another fallacy, are not going to increase the credibility of an already fallacious argumentation. > I think that is a naive approach to assessing other's subjective > decisions without knowing all there decision making constraints. I do not need to know the constraints to show that a decision is not well-founded. > We have also seen over time that you are doing some things objectively > wrong like serving XHTML as HTML. Your fallacies are getting tiresome. > [snip] > >>>> I'm interested in people's comments on this approach. >>> It works. >> It does not. > > It absolutely does work for many users. But not for as many if that path would not have been followed. >> The document is empty. > > That is not an argument about anything. The value of the information in an empty document is zero and can fulfill no purpose but to show that there is no information. I would deem this to be a Bad Thing when the intent is to transport information. >> For a user with disabilities, > > There are other strategies for supporting disabled users other than just > a single page gracefully degrading. I'm sure you can think of at least > five other strategies off the top of your head. Yes, I can. However, I can also see the drawbacks that follow from them and do weigh them against the greater advantages that follow from not implementing them. >> a search engine, > > not all pages are to be indexed or even accessible to a search engine. The truth of this statement depends on how one defines a search engine. >> a user behind a filtering proxy, > > A business decision may be willing to sacrifice these users. Which does not make this business decision a reasonable or economically correct one. In fact, it makes it a rather dubious one if you consider that it is seldom the case that an Web application is solely accessed from within a local area network. >> a user with a not so sophisticated mobile device > > Not all pages need to work on a mobile device. I included "not so sophisticated" for a reason. > As I've established above, a web page will require some describable set > of technologies to access it. It could be that for a particular page the > reader must have a modern desktop computer with a web browser that has > been released in the past year with all the bells and whistles turned on. True. However, since that particular "page" would introduce a barrier that all the other content does not, one has to reconsider whether it is reasonable that this is the case or if it would instead be better if this barrier would not be introduced. >> and so on. You are blinding yourself to the possibilities of access to >> a Web application if you call this nonsense working. > > I think you are jumping to conclusions about my post and you have done > this with other posts of mine in the past. There is really no need to do > that. You could ask questions instead. I don't need to ask questions about particularities in order to make general statements or show arguments to be fallacious. > I also think you are missing the fact that I have pointed out here that > the necessary technology to read a web page is a far more prohibitive > restriction in terms of number of people that can read a page than > JavaScript off is. Even writing a page in only one human language > eliminates billions of potential readers. Apples, oranges. PointedEars |
|
#18
06-01-08, 08:01 PM
|
|
|
|
|
Dan Rumney wrote:
> > By simple HTML editors, I mean things like Notepad, Crimson Editor, > HTML-Kit and the like. I'm not a big fan of Dreamweaver and other > 'visual' editors, but I'd be the first to admit that I probably need > to get over that bias. Your bias is well-founded. Dreamweaver and the like are nasty black boxes that produce lousy, often non-compliant HTML that's difficult to maintain. Use an editor (with syntax highlighting and that sort of thing, if you find it helpful) and write well-structured, concise, elegant HTML, then validate it. The principles of good programming apply to HTML, even though it's just a declarative markup language. Separate concerns: structure your HTML into functional areas, and separate out presentation (CSS) and behavior (Javascript) from content (HTML). Emphasize readability: use whitespace and comments. Identifiers, like style class names and element IDs, should be meaningful. These are not things that most "visual" editors will accommodate well. At best, you'll be switching between "code" and "visual" views; so why not simply operate in the former, since you're comfortable with it already? Visual editors also encourage WYSIWYG thinking, which leads to inflexible layouts and poor rendering for users whose environments don't match the author's. Working directly with the abstractions of HTML and CSS encourages liquid layouts, because you're not looking at one renderer's opinion of your page. |
|
#19
06-01-08, 08:34 PM
|
|
|
|
|
[snip]
> > > It's abundantly clear that anyone using a UA that does not have > > Javascript is not going to be able to access pages generated using the > > model that I outlined in the original post. > > They will if you properly design NOSCRIPT redirect and/or warning > blocks. > Good point. I was taking a limited view as to what 'access' was. Certainly, they won't be able to gain anything fruitful from the specific page that they've pointed their UA at. However, if I use a NOSCRIPT element, I can ensure that they are informed as to the state of the page and, ideally, directed to a page that provides comparable functionality without the need for Javascript. > > I think a more fruitful discussion would focus on other, less obvious > > aspects, which is why I'm seeking the thoughts of others. > > 1) Search recents about Ruby in this group for one (the problem with > script inserting script inserting ...) Thanks for the suggestion. I'll take a look > 2) Another one is specific for charsets above US-ASCII in Javascript > strings, especially in document.write. Maybe it is not your case. Not for me, but perhaps useful to other readers. > 3) Browser screen update mechanics may make _very_ big delay before > any content will get visible unless you are using properly context > releases over setTimeout. By now and IMO it is the most common mistake > made in Javascript / XHR intensive solutions. TBH, I've never seen this. I'm not refuting the possibility; do you know of any sites which demonstrate this behaviour? |
|
#20
06-01-08, 08:53 PM
|
|
|
|
|
On Jun 1, 11:31 am, Thomas 'PointedEars' Lahn <PointedE>
wrote: > Peter Michaux wrote: >> You claimed it to be working. Generally. >> That does not make the result a good one. It may be the very best result under certain business requirements. [snip] > Diminishing an opinion by stating that the topic it discusses is subjective > is fallacious because all opinions are subjective. What matters is if an > opinion is well-founded or not. I think mine is, as I think I have > presented conclusive non-fallacious arguments to support it in the process. yours may be well founded under certain business requirements. You may not be considering other situations which result in other decisions. > > When one decides to publish information on the web only, one is requiring > > a reader to have a computer, > > For suitable values of "computer". Computers come in different forms nowadays. > > > an internet connection > > As much as it may surprise you, it is _not_ a necessity. Content can be > stored while the Internet connection is established and accessed later offline. So at some point an internet connection is required. > > and web browser (or similar program to get content off the web). > > I can accept that as an axiom of no greater value: You need a Web user agent > to access Web content. > > > That is setting the bar quite high > > High for whom? High for those without a computer, internet connection, and/or web browser. > > and expensive. > > Not necessarily. It certainly is expensive to own a computer, internet connection and web browser. For some people going to a 10 peso/hour internet cafe in Mexico is expensive. [snip] > > If a publisher is willing to discard all potentially interested readers > > that do not have an internet connection etc, then the publish could > > subjectively decide that JavaScript is a requirement. > > Which does not mean in any way that this decision is a reasonable one. or an unreasonable one. [snip] > > It has become quite clear over my time reading comp.lang.javascript that > > you believe you know the right way to do things > > At least I can *justify* my design decisions. As can I. [snip] > > I think that is a naive approach to assessing other's subjective > > decisions without knowing all there decision making constraints. > > I do not need to know the constraints to show that a decision is not > well-founded. Then, in my opinion, your decision making process is broken. You cannot engineer something unless you know the requirements. To believe that there is one solution for all situations is naive. > > We have also seen over time that you are doing some things objectively > > wrong like serving XHTML as HTML. > > Your fallacies are getting tiresome. http://groups.google.com/group/comp....e28a4ea7ec2903 > >>>> I'm interested in people's comments on this approach. > >>> It works. > >> It does not. > > > It absolutely does work for many users. > > But not for as many if that path would not have been followed. True. That may not be a net loss, however, when counting profit. > >> The document is empty. > > > That is not an argument about anything. > > The value of the information in an empty document is zero and can fulfill no > purpose but to show that there is no information. I would deem this to be a > Bad Thing when the intent is to transport information. The intent may not be to transport information in a document-like format even though that was the original intent of the web. The web is now being used as an application platform as well. > >> For a user with disabilities, > > > There are other strategies for supporting disabled users other than just > > a single page gracefully degrading. I'm sure you can think of at least > > five other strategies off the top of your head. > > Yes, I can. However, I can also see the drawbacks that follow from them > and do weigh them against the greater advantages that follow from not > implementing them. Do you agree that given certain business constraints perhaps you would weight the advantages and disadvantages differently? [snip] > >> a user behind a filtering proxy, > > > A business decision may be willing to sacrifice these users. > > Which does not make this business decision a reasonable or economically > correct one. It does not make it an incorrect one either. > In fact, it makes it a rather dubious one maybe or maybe not. > if you consider that > it is seldom the case that an Web application is solely accessed from within > a local area network. A web application may be on the general internet with a notice it requires CSS, image, JavaScript, Flash, Quicktime support etc. These would all be reasonable requirements in some circumstances. > >> a user with a not so sophisticated mobile device > > > Not all pages need to work on a mobile device. > > I included "not so sophisticated" for a reason. They don't need to work on not so sophisticated mobile devices. > > As I've established above, a web page will require some describable set > > of technologies to access it. It could be that for a particular page the > > reader must have a modern desktop computer with a web browser that has > > been released in the past year with all the bells and whistles turned on. > > True. However, since that particular "page" would introduce a barrier that > all the other content does not, one has to reconsider whether it is > reasonable that this is the case or if it would instead be better if this > barrier would not be introduced. You certainly are correct for some situations. For others the "wow factor" that JavaScript provides may be the only reason a user decides to use a particular website when others exist without JavaScript or with JavaScript as progressive enhancements. In this situation using JavaScript heavily may be exactly the reason a site is profitable. [snip] Peter |
|
#21
06-01-08, 09:21 PM
|
|
|
|
|
Dan Rumney wrote:
> [snip] >>> It's abundantly clear that anyone using a UA that does not have >>> Javascript is not going to be able to access pages generated using the >>> model that I outlined in the original post. >> They will if you properly design NOSCRIPT redirect and/or warning >> blocks. > > Good point. I was taking a limited view as to what 'access' was. > Certainly, they won't be able to gain anything fruitful from the > specific page that they've pointed their UA at. However, if I use a > NOSCRIPT element, I can ensure that they are informed as to the state > of the page and, ideally, directed to a page that provides comparable > functionality without the need for Javascript. As a `noscript' element can only provide indirect redirection or not at all, less experienced users will be annoyed at you forcing them to perform another navigation step, while more experienced users will rightly call you a script kiddie if you do this. Which is why I mentioned, but recommended against, the better alternative of redirecting from a document that does not require scripting to one that does instead of doing it vice-versa. I strongly recommend not to listen to VK's recommendations for they have been misleading in the past and there is no indication that this could ever change. PointedEars |
|
#22
06-01-08, 10:03 PM
|
|
|
|
|
Peter Michaux wrote:
> On Jun 1, 11:31 am, Thomas 'PointedEars' Lahn <PointedE> wrote: > > So at some point an internet connection is required. A network connection would be required at some point in most cases. >>> and web browser (or similar program to get content off the web). >> I can accept that as an axiom of no greater value: You need a Web user >> agent to access Web content. >> >>> That is setting the bar quite high >> High for whom? > > High for those without a computer, internet connection, and/or web > browser. However, irrelevant to this discussion. >>> and expensive. >> Not necessarily. > > It certainly is expensive to own a computer, internet connection and web > browser. For some people going to a 10 peso/hour internet cafe in Mexico > is expensive. It is not necessarily expensive for someone. Naming examples, public libraries are providing inexpensive Internet access, too. But talking about access costs for access now, you would deny the very people that you talk above about the right to access to information if you required them to have certain non-basic technologies available. Insofar your "business constraints" argumentation is not only hypocritical but proves to be contradictory in itself as you are excluding many potential customers when following it. Have you ever thought about that? >>> If a publisher is willing to discard all potentially interested >>> readers that do not have an internet connection etc, then the publish >>> could subjectively decide that JavaScript is a requirement. >> Which does not mean in any way that this decision is a reasonable one. > > or an unreasonable one. But your argument suggests it must be reasonable because of that, and I have pointed out that this is dead wrong. >>> It has become quite clear over my time reading comp.lang.javascript >>> that you believe you know the right way to do things >> At least I can *justify* my design decisions. > > As can I. But you do not. Instead you are arguing with nebulous business constraints. >>> I think that is a naive approach to assessing other's subjective >>> decisions without knowing all there decision making constraints. >> I do not need to know the constraints to show that a decision is not >> well-founded. > > Then, in my opinion, your decision making process is broken. You cannot > engineer something unless you know the requirements. To believe that > there is one solution for all situations is naive. See below. >>> We have also seen over time that you are doing some things >>> objectively wrong like serving XHTML as HTML. >> Your fallacies are getting tiresome. > > [..] Thanks, I know what I (have to) do. Yours is still a fallacy. >>>>>> I'm interested in people's comments on this approach. >>>>> It works. >>>> It does not. >>> It absolutely does work for many users. >> But not for as many if that path would not have been followed. > > True. That may not be a net loss, however, when counting profit. If one has blinded themselves enough. >>>> The document is empty. >>> That is not an argument about anything. >> The value of the information in an empty document is zero and can >> fulfill no purpose but to show that there is no information. I would >> deem this to be a Bad Thing when the intent is to transport >> information. > > The intent may not be to transport information in a document-like format > even though that was the original intent of the web. The web is now being > used as an application platform as well. Any software application transports information from the back end to the user and vice-versa. >>>> For a user with disabilities, >>> There are other strategies for supporting disabled users other than >>> just a single page gracefully degrading. I'm sure you can think of at >>> least five other strategies off the top of your head. >> Yes, I can. However, I can also see the drawbacks that follow from >> them and do weigh them against the greater advantages that follow from >> not implementing them. > > Do you agree that given certain business constraints perhaps you would > weight the advantages and disadvantages differently? Perhaps. However, it is seldom necessary to bow down to short-term business arguments if you know enough to stand your ground and point out the immediate, mid-term and long-term (financial) advantages of not entirely following the logic those arguments are based on. >>>> a user behind a filtering proxy, >>> A business decision may be willing to sacrifice these users. >> Which does not make this business decision a reasonable or economically >> correct one. > > It does not make it an incorrect one either. It makes it an incorrect one if it is made to achieve short-term profit in the face of mid-term or long-term losses. >> In fact, it makes it a rather dubious one > > maybe or maybe not. > >> if you consider that it is seldom the case that an Web application is >> solely accessed from within a local area network. > > A web application may be on the general internet with a notice it > requires CSS, image, JavaScript, Flash, Quicktime support etc. Apples and oranges again. > These would all be reasonable requirements in some circumstances. No, since HTML degrades gracefully by default, and server-side scripting is readily available. >>>> a user with a not so sophisticated mobile device >>> Not all pages need to work on a mobile device. >> I included "not so sophisticated" for a reason. > > They don't need to work on not so sophisticated mobile devices. Maybe now, since mobile Internet devices are only emerging. > > You certainly are correct for some situations. For others the "wow > factor" that JavaScript provides may be the only reason a user decides to > use a particular website when others exist without JavaScript or with > JavaScript as progressive enhancements. In this situation using > JavaScript heavily may be exactly the reason a site is profitable. Short-term profit does not balance increased long-term maintenance costs, for example. PointedEars |
|
#23
06-02-08, 12:35 AM
|
|
|
|
|
On Jun 1, 2:03 pm, Thomas 'PointedEars' Lahn <PointedE>
wrote: > Peter Michaux wrote: >> > A network connection would be required at some point in most cases. >> > > However, irrelevant to this discussion. I bring it up because of its complete relevance. The point is that a lot of technology is required to view a static HTML page and, although we routinely make a big fuss about it on c.l.js, it is only a tiny step more to add JavaScript as a dependency. JavaScript as a dependency is almost no barrier at all compared to the other requirements. [snip] > >>> It has become quite clear over my time reading comp.lang.javascript > >>> that you believe you know the right way to do things > >> At least I can *justify* my design decisions. > > > As can I. > > But you do not. Instead you are arguing with nebulous business constraints. If you cannot clearly see that business constraints play a role then suppose you were charged with the task of writing interactive video games for the web. The business partners want these to be usable by people with a relatively low barrier. That is, no Flash or Sliverlight or other browser plugins. You are allowed to assume support for HTML, images, cookies, CSS and JavaScript because these are on by default in most browsers. You must support IE6+, FF2+, O9+, S3+. How would you do that so it degrades gracefully without JavaScript support? [snip] > >>>> a user behind a filtering proxy, > >>> A business decision may be willing to sacrifice these users. > >> Which does not make this business decision a reasonable or economically > >> correct one. > > > It does not make it an incorrect one either. > > It makes it an incorrect one if it is made to achieve short-term profit in > the face of mid-term or long-term losses. The way I read that is if your "if" clause does not hold then you are admitting that sometimes it is ok or unavoidable to depend on JavaScript. [snip] Peter |
|
#24
06-02-08, 07:50 PM
|
|
|
|
|
VK and Lahn do seem to enjoy generating a lot of sound & fury around a
topic, eh? <grin> On May 31, 4:53 pm, Dan Rumney <dancr> wrote: > The critical point is that the page is "pre-built" on the server. > > I've been thinking about an alternative approach, whereby the page is > built on the fly with various AJAX calls to the server to pull in the > necessary components. In the extreme, I could visualize doing away > with Perl generated pages entirely. All pages are HTML, with AJAX > calls to the server. The responding scripts would return JSON or XML > data which would be interpreted on the client side as required. > > An advantage to this would be that it would be a lot easier to > generate the pages using simple HTML editors. It would be a lot > simpler to ensure validity of the HTML (as the final product would > always be available to me). > > I'm interested in people's comments on this approach. Does it provide > extra burden on the server? Are there any hidden advantages or > disadvantages I may be aware of? Does anyone know of any white papers > on this approach? My 2 cents: For me, the big consideration in deciding whether to load data all at once or in subsets on demand is the size of the data set that users are pulling down. If it is very large, then AJAX would likely be a huge savings on bandwidth and load time of pages. I do this with sales statistics, myself. There is a lot of data that is POTENTIALLY relevant to the user, but downloading all sales data down to the individual order level for six months would be prohibitive! In this case, I pull down data sets on demand. For things like an user's profile, tho, I load all the data on the server side by embedding it in the page directly. This is much faster than loading the page and then sending a request for the data and then decoding the data and inserting into the HTML dynamically. Security may also be an issue...I often send the user's credentials in the form of a session ID (stored in our DB or by your server side framework like ASP or PHP) in order to validate the request. Otherwise you might easily pipe sensitive data to anyone who can figure out how to create a request. Tyler |
|
#25
06-02-08, 07:57 PM
|
|
|
|
|
Peter Michaux wrote:
> On Jun 1, 2:03 pm, Thomas 'PointedEars' Lahn <PointedE> wrote: > > I bring it up because of its complete relevance. The point is that a lot > of technology is required to view a static HTML page and, although we > routinely make a big fuss about it on c.l.js, No, in order to discuss and decide whether an additional technology is reasonable to use it is completely irrelevant to consider what this technology is based on because the basic stakes are the same whether you use it or not. What is relevant is instead how well the additional technology is supported, and what *additional* effort is necessary in order to have that support. > it is only a tiny step more to add JavaScript as a dependency. JavaScript > as a dependency is almost no barrier at all compared to the other > requirements. That is a fallacy. > > If you cannot clearly see that business constraints play a role then > suppose you were charged with the task of writing interactive video games > for the web. The business partners want these to be usable by people with > a relatively low barrier. That is, no Flash or Sliverlight or other > browser plugins. You are allowed to assume support for HTML, images, > cookies, CSS and JavaScript because these are on by default in most > browsers. You must support IE6+, FF2+, O9+, S3+. How would you do that so > it degrades gracefully without JavaScript support? Just more hot smoke I am therefore going to ignore. If you named *your* business constraints once, one could at least try to evaluate your design decision. >>>>>> a user behind a filtering proxy, >>>>> A business decision may be willing to sacrifice these users. >>>> Which does not make this business decision a reasonable or >>>> economically correct one. >>> It does not make it an incorrect one either. >> It makes it an incorrect one if it is made to achieve short-term profit >> in the face of mid-term or long-term losses. > > The way I read that is if your "if" clause does not hold then you are > admitting that sometimes it is ok or unavoidable to depend on JavaScript. However, that would be another fallacy. PointedEars |
|
#26
06-02-08, 08:11 PM
|
|
|
|
|
On Jun 2, 11:57 am, Thomas 'PointedEars' Lahn <PointedE>
wrote: [snip] >> Just more hot smoke I am therefore going to ignore. If you named *your* > business constraints once, one could at least try to evaluate your design > decision. You are ducking the issue. For the purpose of this discussion these are my business constraints. This is a realistic, possible situation in which a programmer may find himself. I am not trying to suggest depending on JavaScript is good in many situations. I am simply trying to determine if you agree that there are some situations where a dependency on JavaScript may be either necessary or acceptable. [snip] Peter |
|
#27
06-02-08, 08:29 PM
|
|
|
|
|
Peter Michaux wrote:
> Thomas 'PointedEars' Lahn wrote: > > You are ducking the issue. No. You are, hiding behind names when it is high time to put your money on the table. > I am not trying to suggest depending on JavaScript is good in many > situations. I am simply trying to determine if you agree that there > are some situations where a dependency on JavaScript may be either > necessary or acceptable. Knowing me to suggest frequently to use scripting to generate specific elements that only work *with* client-side scripting, however to try to void these, you could have known that already: I know that there are certain special features in a Web application that are not possible to implement without support for client-side scripting. However, that does not mean client-side scripting needs to be a requirement for the entire application nor that it is acceptable if it was defined as a requirement for that. A good example are popup windows: It is OK if there is no popup window on a hyperlink if client-side scripting is unavailable; it is not OK if nothing happens then or the user is bothered with an error message (that they are unlikely to understand). Regarding your approach this means: It is OK if you use client-side scripting and XHR to fill your document; it is not OK if your document remains empty if one of them is not sufficiently supported. As there is an alternative, conventional way to transport the information from the server to the client. PointedEars |
|
#28
06-02-08, 09:10 PM
|
|
|
|
|
On Jun 2, 12:29 pm, Thomas 'PointedEars' Lahn <PointedE>
wrote: > Peter Michaux wrote: >> No. You are, hiding behind names when it is high time to put your money on > the table. I just gave you a realistic set of constraints. What more do you want? > > Knowing me to suggest frequently to use scripting to generate specific > elements that only work *with* client-side scripting, however to try to void > these, you could have known that already: > > I know that there are certain special features in a Web application that are > not possible to implement without support for client-side scripting. > However, that does not mean client-side scripting needs to be a requirement > for the entire application nor that it is acceptable if it was defined as a > requirement for that. A good example are popup windows: It is OK if there > is no popup window on a hyperlink if client-side scripting is unavailable; > it is not OK if nothing happens then or the user is bothered with an error > message (that they are unlikely to understand). > > Regarding your approach this means: It is OK if you use client-side > scripting and XHR to fill your document; it is not OK if your document > remains empty if one of them is not sufficiently supported. As there is > an alternative, conventional way to transport the information from the > server to the client. So it seems you agree that there are at least some situations that require JavaScript. It also seems that you do not feature test all host or native objects you use. That was made clear in late 2007. We also know that you are serving XHTML as HTML. Unfortunately you continue to berate others for similar types of activities. Your criticism of others is contradictory to your own actions. We are all engineering in grey areas of compromise yet you portray this picture of right versus wrong. The standards you are evangelizing are good and admirable, but even you cannot or do not live up to them. You draw a line at one shade of grey while others draw the line at a different shade. They do not need to be ridiculed by you for that because both you and the others are in the grey. No one is "right". comp.lang.javascript's reputation and usefulness suffers because people are berated in an unfriendly way and that those doing the berating are not saints themselves often holding others to standards they do not uphold themselves. I hope you lighten up and realize that sometimes people just don't know what they are doing but that sometimes people are dealing with business constraints out of their control. You are in the case of XHTML as HTML. It would be better if newcomers to the group did not feel like the sharks are attacking when they arrive. Peter |
|
#29
06-02-08, 09:53 PM
|
|
|
|
|
Peter Michaux wrote:
> Thomas 'PointedEars' Lahn wrote: These are requirements. >>>>> You are allowed to assume support for HTML, images, cookies, CSS >>>>> and JavaScript because these are on by default in most browsers. These are _not_ requirements, these are *allowances* (based on false assumptions). You are *free* to implement something that meets these without restricting yourself to them. Specifically, while you are allowed to use JavaScript, you are not at all *required* to. >>>>> You must support IE6+, FF2+, O9+, S3+. These are requirements again. >>>> How would you do that so it degrades gracefully without JavaScript support? As I already described. >>>> Just more hot smoke I am therefore going to ignore. If you named >>>> *your* business constraints once, one could at least try to >>>> evaluate your design decision. >>> You are ducking the issue. >> No. You are, hiding behind names when it is high time to put your >> money on the table. > > I just gave you a realistic set of constraints. What more do you want? Not all of them, and in fact not the ones under discussion here, are constraints. >>> I am not trying to suggest depending on JavaScript is good in many >>> situations. I am simply trying to determine if you agree that there >>> are some situations where a dependency on JavaScript may be either >>> necessary or acceptable. >> Knowing me to suggest frequently to use scripting to generate specific ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^ >> elements that only work *with* client-side scripting, however to try to >> [a]void ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^ >> these, you could have known that already: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> [...] >> Regarding your approach this means: It is OK if you use client-side >> scripting and XHR to fill your document; it is not OK if your document >> remains empty if one of them is not sufficiently supported. As there >> is an alternative, conventional way to transport the information from >> the server to the client. > > So it seems you agree that there are at least some situations that > require JavaScript. *roll eyes* > It also seems that you do not feature test all host or native objects you > use. That was made clear in late 2007. I am not feature-testing all native objects I am using when the language feature can be considered to be universally available. In order to make that assessment and help others with makit it, I am maintaining the ECMAScript Support Matrix. It is a well-founded informed design decision. I should be feature-testing all host objects (including window.alert, as it turned out) but I think probably I do not in all my code at the moment. As you know my postings so well, could you please point me to the posting where I said that not all host objects need to be feature-tested? Because I don't remember saying it. > We also know that you are serving XHTML as HTML. No, because of the server-side XML-based template engine the content management system is based on that we are developing for, we are serving XHTML 1.0 Transitional, "HTML-compatible" per The XHTML 1.0 Specification, Appendix C, as text/html. If I am not developing for the CMS or templating is not required to accomplish the task, I am writing and serving HTML 4.01 Transitional or Strict (as text/html) instead, and suggest this to my colleagues instead. > Unfortunately you continue to berate others for similar types of > activities. [...] I am not going to comment on this new ad-hominem attack-rant of yours. It is a pity that you deem it necessary to resort to such things in order to back up your argumentation. PointedEars |
|
#30
06-03-08, 12:18 AM
|
|
|
|
|
Thomas 'PointedEars' Lahn a écrit :
> Peter Michaux wrote: >> I am not trying to suggest depending on JavaScript is good in many >> situations. I am simply trying to determine if you agree that there >> are some situations where a dependency on JavaScript may be either >> necessary or acceptable. > > Regarding your approach this means: It is OK if you use client-side > scripting and XHR to fill your document; it is not OK if your document > remains empty if one of them is not sufficiently supported. As there is > an alternative, conventional way to transport the information from the > server to the client. Are you, both, talking about a static HTML document or a dynamic web application ? |
|
|
|
|
| Similar Threads | |
| In python CGI, how to pass "hello" back to a javascript function asan argument at client side? Hi everyone, How can I pass a string generated from python cgi at server side to a javascript function as an argument at client side? Here is my case: 1. client... |
|
| Sonicwall global vpn client vista alternative or linux alternative Hi My computer died and being unable to find an xp system at any local tech stores anymore had to get vista only to find out sonicwall global vpn client is well not... |
|
| Any projects to provide Javascript-style client-side browser accessvia Python? I'm curious about this because, quite aside their function as web browsers, it is now possible to build some very useable interfaces using browsers with HTML, CSS, and... |
|
| Python from the command line (was: Choosing Perl/Python for my particular niche) In article <4069F1FD.601C9079>, Fred Ma <fma> wrote: |
|
| Perl/CGI, PHP, ASP, XML, Java, Javascript, C/C++, Flash, Python, and Cold Fusion Etw Webmasters: Colance specialise in connecting your ideas with Freelance Professionals to produce your project. Programmers: Providing your Service is made easy through... |
|
|
All times are GMT. The time now is 07:08 AM. | Privacy Policy
|
Javascript on the client as an alternative to Perl/PHP/Python on theserver